What about Jack support? This could be done as opcodes.

In fact, what about removing all IO and doing it only through plugin
opcodes?

Original Message:
-----------------
From: Matt J. Ingalls ingalls@mills.edu
Date: Tue, 16 Dec 2003 13:16:54 -0800 (PST)
To: csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:3779] Re: REVIEW



thanks john for posting this

> d) The need for a software bus is getting stronger, but I have no
> proposals of a design, let alone any code.  I really want to remove
> the FLTK widgets and the controls outside the main system, and replace
> by generic bus opcodes

i would like to volunteer to do this [or with others]

and in relating this and to portAudio/portMIDI issues, i hope there will
there be a way to compile csound5 kernel without ANY i/o things like
portAudio et al and just use the generic bus?

-m


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

Only if we can ~guarantee~ a default io set is ~always~ available, 
loaded automatically unless overridden by something else, that ~exactly~ 
mimics the current opcodes, so that nothing unusual has to be done to be 
backwards compatible with the thousands of tutorials, lecture notes etc 
out there.

There does surely come a point at which what remains is scarcely 
recognisable as Csound. Do we really want to do that?

If a new user can't copy and run the simplest orch from a book:

instr 1
asig oscili 10000,440,1
outs asig, asig
endin


without having to do something special, we have started to make it 
difficult to do simple things, which is uncool IMO.

I don't see why jack should be implemented by opcodes - they would by 
definition be non-portable. That is a task for the host.

Richard Dobson


gogins@pipeline.com wrote:
> What about Jack support? This could be done as opcodes.
> 
> In fact, what about removing all IO and doing it only through plugin
> opcodes?
> 
...