I'm contemplating the possibility of writing a rather large software-based
emulation of a modular synthesizer, using Csound as the sound engine. This
might or might not be practical from the standpoint of CPU horsepower, and
at the very beginning of the design process I'm seeing what might be a CPU
bottleneck. I'd like to get some feedback on it from those who know far more
than I about the innards of Csound.

Due to the complexity of the design that I'm considering, it's not practical
to use either FLTK panels or CsoundQt widgets to create a user interface.
(CsoundQt doesn't seem to allow more than a single panel full of controls,
which is not nearly enough screen real estate, and while FLTK can easily
create multiple windows, it has no drop-down menu UI device. I need
drop-down menus. Also, the FLTK implementation seems not to be entirely
stable in Windows.)

I can create an interface -- and quite a nice one, I might add -- using
Processing. Processing can easily send OSC messages to Csound. I've tested
this, and it works. Processing can even read hardware MIDI sliders, respond
to them by rotating on-screen knobs, and send the results out as OSC. I've
tested that too.

Unfortunately, the total number of user controls in the project that I'm
envisioning might be more than 1,000. The way OSClisten is set up, on each
k-cycle it will have to look at the OSC input more than 1,000 times, each
time checking to see whether one particular destination string is present.

To my untutored way of thinking, that looks like it could spell trouble.

If it were possible to grab an OSC message with an unknown destination
address from the input buffer and then go through some sort of branching
search tree based on the characters in the address string, the process of
identifying the message and assigning it to a global k-rate variable might
(??) be more efficient. But that's not how OSClisten is set up.

Am I imagining a non-existent problem? Or is it a real problem with a
workaround? (I guess I could brush up on my C, write an opcode, and then
learn to compile Csound myself, but maybe there's an easier way.) Or should
I trash this whole project and buy a hardware modular synth instead?

Thanks for any insights or suggestions!

--JA

P.S.: The project, in case you're curious, was inspired by gazing at the
mouth-watering lineup of modules in a Doepfer analog system and thinking,
"Gee, I'd love to have one of those, but it's soooo expensive! Hey, maybe I
could model a Doepfer in Csound...."



--
View this message in context: http://csound.1045644.n5.nabble.com/CPU-Resources-Question-tp5714969.html
Sent from the Csound - General mailing list archive at Nabble.com.

Hi Jim,

What GUI are you using for Processing? I think Processing, being Java, and
the combination of so much OSC traffic would not be practicle in this case.

Have you thought of using the CSound API and Python with a GUI (either
TKinter or wxPython)?

Richard



--
View this message in context: http://csound.1045644.n5.nabble.com/CPU-Resources-Question-tp5714969p5714970.html
Sent from the Csound - General mailing list archive at Nabble.com.

On 08/19/12 03:46, zappfinger wrote:
> Hi Jim,
>
> What GUI are you using for Processing? I think Processing, being Java, and
> the combination of so much OSC traffic would not be practicle in this case.

I've already seen a few synth GUIs created with Processing. They were 
quite responsive, but I don't think the OSC traffic was anything near 
Jim's plan.

AVSynthesis is a Java-based environment, it runs like a champ on my 
machines.

> Have you thought of using the CSound API and Python with a GUI (either
> TKinter or wxPython)?
>

Also good choices. I'm impressed with how far these GUI toolkits have come.

Best,

dp

On 08/19/12 00:50, Jim Aikin wrote:
> ...
>
> I can create an interface -- and quite a nice one, I might add -- using
> Processing. Processing can easily send OSC messages to Csound. I've tested
> this, and it works. Processing can even read hardware MIDI sliders, respond
> to them by rotating on-screen knobs, and send the results out as OSC. I've
> tested that too.

Good to see more work in that direction. Processing has much potential 
for building control interfaces.

Very interesting project, Jim, good luck with it.

> Unfortunately, the total number of user controls in the project that I'm
> envisioning might be more than 1,000...
> P.S.: The project, in case you're curious, was inspired by gazing at the
> mouth-watering lineup of modules in a Doepfer...

Ah, shoot. I was hoping you were going for the Jupiter 8 or an MKS80. 
But I won't be disappointed if you build a Csoundish Doepfer. :)

Best,

dp

interesting project. i'd love to see a prototype of this interface in 
processing, and the corresponding csound code.

i don't know anything about the performance of the two solutions you 
describe. but i am wondering whether it is not a nicer way of 
programming to send the osc messages more general, and then split them 
in csound, instead of having so many different osc listen lines of code 
in csound.

	joachim


Am 19.08.2012 06:50, schrieb Jim Aikin:
> I'm contemplating the possibility of writing a rather large software-based
> emulation of a modular synthesizer, using Csound as the sound engine. This
> might or might not be practical from the standpoint of CPU horsepower, and
> at the very beginning of the design process I'm seeing what might be a CPU
> bottleneck. I'd like to get some feedback on it from those who know far more
> than I about the innards of Csound.
>
> Due to the complexity of the design that I'm considering, it's not practical
> to use either FLTK panels or CsoundQt widgets to create a user interface.
> (CsoundQt doesn't seem to allow more than a single panel full of controls,
> which is not nearly enough screen real estate, and while FLTK can easily
> create multiple windows, it has no drop-down menu UI device. I need
> drop-down menus. Also, the FLTK implementation seems not to be entirely
> stable in Windows.)
>
> I can create an interface -- and quite a nice one, I might add -- using
> Processing. Processing can easily send OSC messages to Csound. I've tested
> this, and it works. Processing can even read hardware MIDI sliders, respond
> to them by rotating on-screen knobs, and send the results out as OSC. I've
> tested that too.
>
> Unfortunately, the total number of user controls in the project that I'm
> envisioning might be more than 1,000. The way OSClisten is set up, on each
> k-cycle it will have to look at the OSC input more than 1,000 times, each
> time checking to see whether one particular destination string is present.
>
> To my untutored way of thinking, that looks like it could spell trouble.
>
> If it were possible to grab an OSC message with an unknown destination
> address from the input buffer and then go through some sort of branching
> search tree based on the characters in the address string, the process of
> identifying the message and assigning it to a global k-rate variable might
> (??) be more efficient. But that's not how OSClisten is set up.
>
> Am I imagining a non-existent problem? Or is it a real problem with a
> workaround? (I guess I could brush up on my C, write an opcode, and then
> learn to compile Csound myself, but maybe there's an easier way.) Or should
> I trash this whole project and buy a hardware modular synth instead?
>
> Thanks for any insights or suggestions!
>
> --JA
>
> P.S.: The project, in case you're curious, was inspired by gazing at the
> mouth-watering lineup of modules in a Doepfer analog system and thinking,
> "Gee, I'd love to have one of those, but it's soooo expensive! Hey, maybe I
> could model a Doepfer in Csound...."
>
>
>
> --
> View this message in context: http://csound.1045644.n5.nabble.com/CPU-Resources-Question-tp5714969.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
> Send bugs reports to the Sourceforge bug tracker
>              https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>

Or even not using OSC in Csound at all, but just API calls. If OSC is needed it can be captured at the Processing layer.

Victor
On 19 Aug 2012, at 12:30, joachim heintz wrote:

> interesting project. i'd love to see a prototype of this interface in processing, and the corresponding csound code.
> 
> i don't know anything about the performance of the two solutions you describe. but i am wondering whether it is not a nicer way of programming to send the osc messages more general, and then split them in csound, instead of having so many different osc listen lines of code in csound.
> 
> 	joachim
> 
> 
> Am 19.08.2012 06:50, schrieb Jim Aikin:
>> I'm contemplating the possibility of writing a rather large software-based
>> emulation of a modular synthesizer, using Csound as the sound engine. This
>> might or might not be practical from the standpoint of CPU horsepower, and
>> at the very beginning of the design process I'm seeing what might be a CPU
>> bottleneck. I'd like to get some feedback on it from those who know far more
>> than I about the innards of Csound.
>> 
>> Due to the complexity of the design that I'm considering, it's not practical
>> to use either FLTK panels or CsoundQt widgets to create a user interface.
>> (CsoundQt doesn't seem to allow more than a single panel full of controls,
>> which is not nearly enough screen real estate, and while FLTK can easily
>> create multiple windows, it has no drop-down menu UI device. I need
>> drop-down menus. Also, the FLTK implementation seems not to be entirely
>> stable in Windows.)
>> 
>> I can create an interface -- and quite a nice one, I might add -- using
>> Processing. Processing can easily send OSC messages to Csound. I've tested
>> this, and it works. Processing can even read hardware MIDI sliders, respond
>> to them by rotating on-screen knobs, and send the results out as OSC. I've
>> tested that too.
>> 
>> Unfortunately, the total number of user controls in the project that I'm
>> envisioning might be more than 1,000. The way OSClisten is set up, on each
>> k-cycle it will have to look at the OSC input more than 1,000 times, each
>> time checking to see whether one particular destination string is present.
>> 
>> To my untutored way of thinking, that looks like it could spell trouble.
>> 
>> If it were possible to grab an OSC message with an unknown destination
>> address from the input buffer and then go through some sort of branching
>> search tree based on the characters in the address string, the process of
>> identifying the message and assigning it to a global k-rate variable might
>> (??) be more efficient. But that's not how OSClisten is set up.
>> 
>> Am I imagining a non-existent problem? Or is it a real problem with a
>> workaround? (I guess I could brush up on my C, write an opcode, and then
>> learn to compile Csound myself, but maybe there's an easier way.) Or should
>> I trash this whole project and buy a hardware modular synth instead?
>> 
>> Thanks for any insights or suggestions!
>> 
>> --JA
>> 
>> P.S.: The project, in case you're curious, was inspired by gazing at the
>> mouth-watering lineup of modules in a Doepfer analog system and thinking,
>> "Gee, I'd love to have one of those, but it's soooo expensive! Hey, maybe I
>> could model a Doepfer in Csound...."
>> 
>> 
>> 
>> --
>> View this message in context: http://csound.1045644.n5.nabble.com/CPU-Resources-Question-tp5714969.html
>> Sent from the Csound - General mailing list archive at Nabble.com.
>> 
>> 
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>> 
>> 
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie

> Have you thought of using the CSound API and Python with a GUI (either
TKinter or wxPython)? 

I hadn't considered it, because I had never heard ot TKinter or wxPython,
and barely understand Python. I have a tendency to stick with technologies
that I know. It's hard enough for me to make _them_ work! But I'll look into
it. Thanks for the suggestion.



--
View this message in context: http://csound.1045644.n5.nabble.com/CPU-Resources-Question-tp5714969p5714988.html
Sent from the Csound - General mailing list archive at Nabble.com.

> interesting project. i'd love to see a prototype of this interface in
> processing, and the corresponding csound code.

When I get a bit further along, I'll send you the code so you can look at
it.

> i don't know anything about the performance of the two solutions you
> describe. but i am wondering whether it is not a nicer way of
> programming to send the osc messages more general, and then split them
> in csound, instead of having so many different osc listen lines of code
> in csound. 

Yes, after I posted that message and was getting ready for bed, it occurred
to me that I was going about it using brute force rather than being smart. I
think I'll easily be able to set it up so that there are no more than a
dozen OSC message types, total. I'll use the second parameter of the message
to run through an if/then/else block in Csound and route the third parameter
(the actual data) to the appropriate destination.



--
View this message in context: http://csound.1045644.n5.nabble.com/CPU-Resources-Question-tp5714969p5714989.html
Sent from the Csound - General mailing list archive at Nabble.com.

Looking at the online materials describing tkinter, I was unable to find a
single example of a graphic UI developed using it. I did find a list of its
controller widget classes, however. Apparently it has neither knobs, nor
sliders, nor a tabbed main window -- all of which ControlP5 has in
Processing.

The wxPython page I glanced at doesn't list a set of graphic control widget
classes at all. There's a page of screenshots, but they all seem to be of an
IDE, not of a finished piece of design work.

Can anyone point me in the direction of a tkinter or wxPython UI that looks
even vaguely like anything that could be attached to a musical instrument?



--
View this message in context: http://csound.1045644.n5.nabble.com/CPU-Resources-Question-tp5714969p5714990.html
Sent from the Csound - General mailing list archive at Nabble.com.

Hi Jim,

I think one solution that would increase flexibility is to create the CSD and use chnget for values you expect to receive externally. Then, in the host program you can handle mapping OSC or whatever input to channels. This will make the CSD portable, should you want to later add other controller mappings or move the CSD to Android or iOS.

Steven

Hi Jim,

Attached python file uses tkinter and has an input slider with VU meter(not
used in this example), an ADSR with 4 sliders and an output stereo VU meter
with a slider.
It is far from complete or correct but it should run with the attached CSD
file.
Note that the csd file is expected to be in a folder /csds, relative to the
python file.

http://csound.1045644.n5.nabble.com/file/n5714993/genGUI.py genGUI.py 
http://csound.1045644.n5.nabble.com/file/n5714993/adsrGUI.csd adsrGUI.csd 

Richard



--
View this message in context: http://csound.1045644.n5.nabble.com/CPU-Resources-Question-tp5714969p5714993.html
Sent from the Csound - General mailing list archive at Nabble.com.

> I think one solution that would increase flexibility is to create the CSD
and use
> chnget for values you expect to receive externally. Then, in the host
> program
> you can handle mapping OSC or whatever input to channels. This will make
> the
> CSD portable, should you want to later add other controller mappings or
> move
> the CSD to Android or iOS. 

I'm all for flexibility and portability, but I'm not sure what you mean by
"host program." At the moment, I have Csound and Processing running side by
side on a single computer. Neither is the host.

I've been thinking I'll let each instr handle its own OSC receiving, as this
is more object-oriented and reduces code bloat. I _could_ write a separate
instr that would receive all OSC messages and translate them into chnset
messages, but that sounds like a lot of extra work (plus a bit of extra CPU
usage) that at the moment would gain me nothing.

I'm already pushing the boundaries of my skill set ... I wouldn't even have
a clue how to use the Csound API.



--
View this message in context: http://csound.1045644.n5.nabble.com/CPU-Resources-Question-tp5714969p5714996.html
Sent from the Csound - General mailing list archive at Nabble.com.

> Note that the csd file is expected to be in a folder /csds, relative to the
python file. 

...and we have now reached the limit of my understanding. I've put the .py
file in a folder and created a folder called csds within the first folder.
I've placed the .csd file in the latter folder.

When I double-click on the .py file (which my OS does indeed know is a
Python file), a Command Prompt window opens up, remains black, and promptly
closes.

I'd like to see what your example does! But in any event, I doubt it will
show me the full range of graphic widgets that could be created with a
Python library.



--
View this message in context: http://csound.1045644.n5.nabble.com/CPU-Resources-Question-tp5714969p5714997.html
Sent from the Csound - General mailing list archive at Nabble.com.

 It seems you are on Windows? ( I am on OS X)
You can start the Python editor, named Idle, load the py file and run it
from there.

Richard



--
View this message in context: http://csound.1045644.n5.nabble.com/CPU-Resources-Question-tp5714969p5714998.html
Sent from the Csound - General mailing list archive at Nabble.com.

> I think one solution that would increase flexibility is to create the CSD
and use
> chnget for values you expect to receive externally. Then, in the host
> program
> you can handle mapping OSC or whatever input to channels.

Here's a question for you, Steven, since I know blue is written in Java.

Processing is basically Java, although my impression is that it's kind of an
oddball subset or sugar-coated version of Java. And there's a Csound API for
Java.

How hard would it be to import csnd.jar into Processing? I've just now tried
it, and I couldn't make it work. Processing is complaining that it can't
find the library file, although the file is in the right place as far as I
can see, and the syntax of my code appears correct. I suspect the error
message is probably referring to some other problem. Perhaps .jar files for
Processing need to be compiled in some other manner. I would have no clue
about that, and wouldn't understand the technical discussion if I read it.

One reason this would be an interesting and possibly very effective approach
to designing an instrument is that Processing will build free-standing apps.
I think this idea is worth pursuing. Can you (or someone else) suggest how I
might get the Csound API imported into Processing?



--
View this message in context: http://csound.1045644.n5.nabble.com/CPU-Resources-Question-tp5714969p5714999.html
Sent from the Csound - General mailing list archive at Nabble.com.

Hi Jim,

I'll try to explain the host program in another email when i have some time. For processing and csnd.jar, I think Jacob Joaquin (csoundo is think is the name) and Joachim Heintz have writings online.

Steven

Hi Peiman,

You can just comment the import debug line out, it is not required.
Like this:

#from debug import *

Richard





--
View this message in context: http://csound.1045644.n5.nabble.com/CPU-Resources-Question-tp5714969p5715003.html
Sent from the Csound - General mailing list archive at Nabble.com.

Ok, I see it now. Yes, you do need the csnd library, that is your link to the
API.
I think it came with my version of Csound (5.14)

Richard



--
View this message in context: http://csound.1045644.n5.nabble.com/CPU-Resources-Question-tp5714969p5715006.html
Sent from the Csound - General mailing list archive at Nabble.com.

Very briefly, I also think that using processing to create the gui will probably be the easiest for you, then use csoundo to allow the use of the Csound API directly from within processing. You'll have to learn how to use the Csound API, but for the rest you can rely on what you already know. Beware that I don't actually know processing, but can see no reason why this would not work. In this setup, processing will be the'host', and Csound will run as a module within processing.
Best, Oeyvind.