Re: [octal-dev] RE: Objectives FAQ

[David O'Toole]

Timo Tossavainen wrote:

> Well, actually this just needs one new parameter type: file. I mean that

This can probably be added. 

> some modules might not be completely portable (i.e. have an xwin gui for
> editing parameters), 

As long as this isn't done within plugins, doing an external GUI should
be ok. (For technical reasons it won't work from within plugins.) 

> The GUI could have been better IMO. The pattern-editing wasn't as
> well designed as in fasttracker... that part could use some polishing.
> Well, we'll have to wait for Buzz 2 or OCTAL to improve on that.

Yes, I'm planning to tidy up some of the loose ends with editing
(cut/paste etc)

> And it's the right decision for the scope of the project IMO. I added
> feedback to my library mainly for the purpose of prototyping synthesis
> and fx algorithms...

I think that it would be cool for the two to work together; what I was
writing about in the mail before is that some tasks are better done by
using a separate tool with OCTAL. For instance, I would prefer to use an
existing interactive granular synth and then create samples for use with
a tracker; integrating such a program as part of OCTAL might not be
worth it. Doing things in a modular fashion makes the individual parts
much easier to work with. 

So people could use CSound or your libmsp for prototyping and
experimenting, and then they could either use the data files produced,
or maybe implement new algorithms as OCTAL plugins. 

> BTW, have you considered making the plugins callback to OCTAL.
> You could do this with shared objects (libmsp uses it, very handy).
> When you load a plugin, the .so calls back to add the plugin
> (or multiple) to a list.

The plugins are totally separate shared objects which export the OCTAL
API; OCTAL binds to them all dynamically and places the "machine types"
into a central registry at startup time. (I have to link at run time
this way, because each plugin exports functions named "ox_work()" ,
"ox_update()" etcetera, and the names would otherwise collide. 

The function pointers are for the most part wrapped/hidden, and in
places where this isn't done yet, it will be. Some people find function
pointers messy (I don't) but it gives more flexibility. 


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