Re: (no subject)

Hey Iain,

Thanks for the reply!

>
> Hi Nathan. Yes, Glyn and I have done all of the above. The main 
> problem I find is that doing a GUI in csound is a bit of a performance 
> drain, as well as not the most elegant way of making a GUI. The method 
> we wound up using was to store all instrument paramaters that one 
> wants to change dynamically in csound tables. The GUI or user 
> interface without gui ( ie midi input only, no writing to screen ) 
> then writes to those tables. This has a number of advantages, you can 
> use the macro system to make editing patches easy, you can save and 
> load the patch tables with all the ft_blah opcodes, and you can edit 
> them as plain text files and load em up using GEN 23. It's also very 
> easy to turn on and off the gui.
>
Oh neat! At first I was thinking of the gui generating just midi data 
and acting as a controller, but if communicating with csound via files 
could bypass the encoding to midi for gui events and the decoding for 
csound processing, that would work out well and increase the speed.

With the table approach, the control program writes any changes in state 
to disk while csound reads from the file at a set rate? Do you need to 
use a ram based file system to communicate between the both of them and 
speed up access?

I'll have to read more about this approach.

> Personally I am looking forward to exploring this area further with 
> csound5, as we will be able to put csound in one thread or process of 
> a containg C or C++ program, and the gui/user interface in another 
> with lower priority. These can communicate with each other and with 
> the csound tables via the wonderful new CsoundAPI. I'm convinced this 
> is the direction to go for GUIizing csound instruments. I plan on 
> exploring that this summer after my current deadline goes by.

I haven't heard much about the new features of csound5, but running the 
gui sequencer and csound in different processes would be really awesome.

New csound API? Csound will be able to act as a server now, 
communicating via an IPC through the API? Sounds like neat stuff!

>
> If you want to look at a design for a sequencer engine you can go look 
> at the sample code I put up at www.xornot.com I have recently 
> rethought the clocking though, and will be changing how it clocks in 
> order to allow the sequencer engine to play alongside a normal score 
> in perfect sync. I'll mention that on the list once it's up on the 
> site, but again I don't anticipate having time to do that till July.

Thanks, I'll definitly check it out!

> Yup yup. We're doing it in 100% csound! Well actually we also did a 
> dual csound / PD rig.

Sweet! that would be really powerful. Do you have any recordings of it 
in action?

> Another option for gui stuff is to do the gui in PD ( easy! ) and have 
> it communicate with csound tables by making a csound instrument who's 
> job it is to just write a number to a table and then die off. This is 
> really handy for communcating with csound in any way you want via 
> midi. I use the midiin opcode for that or use the -Lstdin option and 
> actually send a score event to csound in text score language. So 
> there's a little csound instrument that takes as pfields the target 
> table number, target table index, and data to write there. After 
> writing once it kills itself with turnoff.

Having a program pipe to csound via standard in would be great removing 
abit of midi processing!

At first I was thinking writing a sequencer that communicates with 
csound using pure midi, but now it seems
to get the best speed its might be possible to process instrument 
variable control data by having a csound intrument read in variables 
from a disk file at a set rate? Putting this file in a ram based file 
system to speed up access, and having the sequencer write to the file on 
every application state change?

And for note/instrument on events, having csound read from stdin, and 
the having the sequencer write to the stdin of csound? And involking 
csound on a thread or process of the sequencer itself for the whole process?

I'd better get back to reading ^^

Thanks,
nathand
_______________________________________________
csoundtekno mailing list
[email protected]

Subscribe, unsubscribe, change mailing list options:
http://plot.bek.no/mailman/listinfo/csoundtekno