Re: [Octal-dev] Re:Octal Machines

[Dave O'Toole]

Richard Wesley Todd wrote:

> Being new to real-time music systems (I'm a CSound guy), I'm interested to

Welcome aboard :-). 

> 2) The ox_api says it ox_work() makes sound return 1, otherwise 0.  I
> think this would be cleaner (and easier to remember) with #defines.

That's a good suggestion; I will add some little macros soon. 

> 1) Is there a planned mechanism by which machines can get, for instance,
> the current sample rate (or at least send it with ox_create)?

There are several options I'm considering. Like in Buzz, none of them
involve different machines having different sampling rates in one
song--they all operate at the output rate. Conveniently this means the
engine doesn't need to think about downsampling and/or rate conversions
and all that. Which is nice, since it's also going to be doing the
mixing.  

I'm thinking either a compile-time constant, or a user-configurable
(per-song) item. In the former case, machines access the macro OX_RATE.
In the latter, there might be a field added to struct machine_type. 

> 3) The idea to do a literate programming approach is great! I use noweb
> for my projects.

The mini-system I'm planning is similar in that it doesn't pretty-print
the source. C is very difficult to read when typeset in a proportional
font!

> 4) Can an interconnected group of machines be treated as one simple
> machine by the interface (i hope this is clear---complexity hiding
> like using millions of transistors but just dealing with a simple
> square 'Pentium')?  I think that would be a nice feature...but then again
> I'm thinking in terms of csound and maybe 'tracking' isn't so much about
> this type of thing.

I'm not sure whether or not this feature is going to happen. This was
one of the first issues that came up when I started researching last
year; after mine and others' experiences with the new modular tracking,
it isn't clear what features of conventional audio languages will and
won't be relevant. Please check out the URL below to see a relevant
posting from a while back. Particularly the point on polyphony: 

http://mail.gnu.org/pipermail/octal-dev/2000-April/000065.html

So far it looks like "chunk-making" process would be highly nontrivial.
There are several possible answers to "what interface does a
macro-object export?" 

Scenario 1:  We want to be able to script/control the behavior of macro
objects. So we need it to export some combination of the internal
objects' constituent interfaces. There might not be a way for the
computer to automatically choose any *intelligent* "new interface"; it
might be huge, so the user will have to pick and choose. Also, now that
multiple plugins are masquerading as one (which is a UI issue) it has to
export a single audio input and an output. The user must also choose
where those go. 

This scenario is especially bad if there is (eventually) any
custom-interface drawing going on. I think this is going to be lots and
lots of code to implement this feature in any meaningful way. 

Scenario 2:  We "black-box" the macros and don't control what's inside.
This solves the interface problem, but at the cost of making macros kind
of uninteresting. 

Obviously #2 is undesirable. My current opinion is that at some point
Scenario 1 is going to get so complex and unwieldy that people will just
write writing plain plugins, which is the whole point anyway. 

I'm not currently 100% decided on this. I don't know if there's any
sensible way to implement #1. Number 2 would be simpler, but really kind
of useless. On top of that, I'm not sure whether macros make sense in a
Buzz-like environment, where the use of high-level plugins is itself
designed to reduce or eliminate the musician's dependence on macro
tricks and other "visual programming" games.  

-- 
@@@ david o'toole
@@@ address@hidden
@@@ www.gnu.org/software/octal