[chuck-users] translating a pd patch to chuck

[altern]

> One interesting idea would be to use OSC to communicate between ChucK  
> and an external Python/Java/etc. agent, but wrap the OSC code on the  
> ChucK end in user friendly convenience classes.  For example, the end  
> user would write something like MySlider.setValue(), but that  
> function would just be sending the appropriate OSC messages behind  
> the scenes.  This could be written entirely in ChucK and Python/etc.,  
> without requiring a custom chuck.  The user would only be seeing  
> ChucK code, and the OSC would be completely transparent.

This is just a quick hack of what you proposed and i can see that the 
possibilities are pretty interesting.

I just took some basic widgets from the wxpython demo that i think are 
interesting for a sound/music GUI. I extended the classes so that they 
send OSC messages when they are used. The result is pretty nice and the 
code (in python yet) could hardly be easier. The attached zip contains 
three files, oscapp.py is just a stupid python file that listens to OSC 
messages from the widgets GUI (sorry i am better at python than ChucK so 
i did all in python at this stage, anyone want to do a chuck example?), 
the example.py file is an example of how to use the widgets, the 
wxmirra.py is a module containing the classes for the widgets the 
wxapplication / wxframe.

Dependencies are python, wxpython and simpleosc. Not that bad since 
wxpython and python are to be included in OSX 10.5. And there are easy 
to use installers for windows and osx. SimpleOSC is just a library we 
created and there is no need to install it, just copy it next to the 
python working example.
python - www.python.org
wxpython - www.wxpython.org
simpleosc - www.ixi-software.net/content/body_backyard_python.html
There is also the possibility to create exe and mac apps with py2exe and 
py2app out of the python examples. Dead easy usually.

The widgets are created passing few arguments like this:
Number(self.frame, "/num1", 'number test', (300, 140), value=12, 
range=(3, 155))
being '/num' the address for the osc message that this widget will send 
when it is used. The rest are just properties for the initial state of 
the widget like position, size, label, range, initial value ...

Labels are not yet working in some widgets. It is in the to do list. 
There is a welcome osc message between the widgets server and the client 
but it is not really needed, I just did it to be able to see if 
connection was ok while coding and display the connection status on the 
status bar.

Next step would be to define a OSC system to control the server from 
ChucK so that there is no need to use python at all. I am not sure how 
difficult this would be but in principle doesnt sound that bad.

The main problem I see with this osc widget server approach is that 
because of OSC it wont be fast enough for some widgets such as a 
real-time spectrum or wave display. However if this goes further it 
could be used as a prototype for a future implementation in C wrapped by 
ChucK.

I will put all this on our svn server soon, but at the moment is being 
moved to another machine and i have to catch up with this yet. I hope to 
be working on and off on this over the next weeks.

ideas/suggestions welcome.

enrike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wxmirra.zip
Type: application/zip
Size: 3589 bytes
Desc: not available
Url : http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20070103/3dd4c2b1/attachment.zip