[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Octal Issues

From: Johan Boulé
Subject: Re: Octal Issues
Date: Sun May 6 19:03:04 2001


FIRST SCENARIO: "One hundred things to keep in mind during Octal developpment"

[00] Every thing is object. (no more fucking `classical' programming => no 
wrapper => real polymorphism)
[01] A processor have several input and/or output ports.
[02] A port has a buffer which can eventually be shared with another port 
("running in place").
[03] Each buffer has a down-sampling factor (some DSP processing need this, 
limited to a power of 2)
[04] Each sample of a buffer has a boolean indicating wether this sample 
shouild be processed or skipped.
[05] Each port and buffer has its own number of channels (=> mono or stereo 
white noises produced by the same processor)
[06] Parameters controled by events don't exist, it must be another input port.
[07] A note sequencer is like any other signal generator, connected to the 
frequency port of an oscillator.
[08] Any output port is connectable to any input port (a stream of signal can 
represent any kind of information).
[09] to [48] http://johan.boule.online.fr/SoftSynth/SoftSynth%20documentation 
("processor" = "machine")
[49] to [98] http://www.objektsynth.com
[99] We are in 2005. Kylix is free on Linux. 
http://www.objektsynth.com/sounds/asz.mp3 Octal is ready for release.

SECOND SCENARIO "wouldn't break any source code of existing machines"

[00] We are in September. First Octal alpha/beta released.
[01] The day after, a new GNU project starts called RMSNO or "Really Modular 

Who said "trivial" twice ?

> > This sounds like a very interesting technique.  Makes me think - would
> > it be better to generalize machine I/O and allow arbitrary numbers of
> > ins/outs?
> Eventually yes. I've had this possibility in mind, and it would be trivial
> to extend the API in this fashion (wouldn't break any source code of
> existing machines.)

"Eventually" = for Octal "Final" version ? (G)
> I thought I would generate some discussion if I asked for opinions on some
> issues coming up:
> [1] RUNNING IN PLACE. Usually the input and output buffers for an Octal
> machine will be distinct; you read from the input buffer, process, and
> write to the output buffer. One optimization would be to allow, in certain
> instances, the input and output buffers to be the same buffer in memory,
> so that you come in with a buffer, process the buffer in place, and when
> you finish the buffer has been reverbed or pitchshifted or whatever.
> Now obviously that won't work in situations where the output of the
> previous machine is also routed to other destinations (you need the
> original copy again) but in the common "chains of effects" it would be a
> good optimization.
> I imagine many plugins wouldn't care if the input buffer was the same as
> the output. If Octal sees that the chain could be optimized (1-1
> connections) then it could simply generate instructions for the mixer to
> run them in place. But there may be instances where a plugin won't work
> running in place.
> Could machine developers give feedback on this? What kind of machines
> would not work with running in place? Should we have a machine-type
> attribute that basically says "don't optimize me to run in place" for
> those machines, and just assume it's allowed for other machine types? This
> would be trivial to add.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]