right now in order to solve the problem of translating my patch i think maybe the easiest solution would be to use the pd GUI i already have to control chuck with OSC.

Hey Enrike You might consider using the SwingOSC http://www.sciss.de/swingOSC/ - an OSC GUI server, originally made for SuperCollider, but I can't see any reason not to use it with ChucK. (there are some PD (i.e. using SwingOSC with PD) examples in the distribution) - This way you could even build one GUI and choose which soundengine to use or use many at the same time (ChucK, PD, SC, : )

altern wrote:

thor wrote:

...

...

right now in order to solve the problem of translating my patch i think maybe the easiest solution would be to use the pd GUI i already have to control chuck with OSC. Hey Enrike

You might consider using the SwingOSC

http://www.sciss.de/swingOSC/

- an OSC GUI server, originally made for SuperCollider, but I can't see any reason not to use it with ChucK.

(there are some PD (i.e. using SwingOSC with PD) examples in the distribution)

- This way you could even build one GUI and choose which soundengine to use or use many at the same time (ChucK, PD, SC, : )

of course. i forgot about this. I guess i could as well use wxpython with osc, maybe not that difficult for simple stuff like this.

and there's OSCSurface: http://joerg.piringer.net/index.php?href=software/oscsurface.xml&mtitle=software i was thinking about translating it into wxPython, but i am not sure if i'll have the time to do it. best joerg -- http://joerg.piringer.net http://www.transacoustic-research.com http://www.iftaf.org http://www.vegetableorchestra.org/

On Dec 28, 2006, at 2:02 AM, altern wrote:

joerg piringer wrote:

...

altern wrote:

...

thor wrote:

...

...

right now in order to solve the problem of translating my patch i think maybe the easiest solution would be to use the pd GUI i already have to control chuck with OSC. Hey Enrike

You might consider using the SwingOSC

http://www.sciss.de/swingOSC/

- an OSC GUI server, originally made for SuperCollider, but I can't see any reason not to use it with ChucK.

(there are some PD (i.e. using SwingOSC with PD) examples in the distribution)

- This way you could even build one GUI and choose which soundengine to use or use many at the same time (ChucK, PD, SC, : ) of course. i forgot about this. I guess i could as well use wxpython with osc, maybe not that difficult for simple stuff like this.

and there's OSCSurface: http://joerg.piringer.net/index.php?href=software/ oscsurface.xml&mtitle=software i was thinking about translating it into wxPython, but i am not sure if i'll have the time to do it.

yes i remember this, but i am working on linux at the moment. Just wondering, how difficult would it be to create a ChucK wrap around a scaled down version of wxWidgets? just wrapping the widgets that are more likely to be used on a music project (sliders, buttons, some graphics to display waves...). A bit like what maui_gui is doing but as a module for the language without depending on the editor.

That would be awesome! There are a few obstacles though. Chiefly, all of the actual GUI code needs to be in a single thread, and that shouldn't be the ChucK VM/audio thread because the GUI code could cause the audio to skip. So each GUI function call needs to go through a thread safe message passing interface between the VM thread and GUI thread, which make writing the wrapper a bit more difficult.

I am thinking on something completely integrated on chuck (like the Supercollider gui). I am happy to use python for anything but many Chuck users just want to do chuck and dont want to deal with extra things.

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. spencer

...

best joerg

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

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

hi joerg joerg piringer wrote:

works great! i'd like to contribute once the svn server is up. i could for example add code for my simple xy-control & maybe wiimote support.

great! the server is up but i am getting some permission errors, i hope this would be solved in couple of days. On the mean time check the attachment. I did some changes making it a bit simpler. This morning i worked on a chuck example for the client. It is included on the zip and it is called oscapp.ck. I added as well a readme.txt file where i describe the python API for the widgets and main server app. I added as well the possibility to pass the application and executable and a patch, then it tries to run the patch with the executable. So i am passing 'chuck', 'oscapp.ck' and this runs the patch with chuck under the wx process. I was bored of having to open two terminals :) On windows and osx i guess it needs to point to the chuck executable, i am on Linux and chuck is on the path. All this means that using py2exe/py2app it is possible and very easy to create standalone exe/app of the guis/chuck patches. Of course this needs chuck.exe /chuck.app to be included in the subfolders. I can create a setup.py file that automatically packs the whole thing including files in a subfolder called 'data' where the patch and chuck executable can be included. I am doing this on a ixi app i am working so it would actually be very easy to adapt the script. On a different direction I was considering how to allow chuck to talk to the widgets server to be able to define the gui from chuck. I already have some parts of it done but not totally sure how to go about it.

one problem i ran into: one of the sockets isn't closed when i exit the app, so starting it again yields the following error:

Traceback (most recent call last): File "C:\developer\wxmirra\example.py", line 19, in ? MyApp(size=(400, 350), fps=10) File "C:\developer\wxmirra\wxmirra.py", line 155, in __init__ self.oscIn = osc.createListener(port=inPort) # in this case just using one socket File "C:\developer\wxmirra\osc\oscAPI.py", line 51, in createListener l.bind( (ipAddr, port) ) File "<string>", line 1, in bind error: (10048, 'Address already in use')

I think this might be a problem with the osc.py which was developed n by daniel holtz, we just did a wrap with a set of functions to ease its use. I guess the ports need to be closed when the library quits. hehe ... this looks good. enrike

joerg piringer wrote:

altern wrote:

...

I added as well the possibility to pass the application and executable and a patch, then it tries to run the patch with the executable. So i am passing 'chuck', 'oscapp.ck' and this runs the patch with chuck under the wx process. I was bored of having to open two terminals :)

i think you forgot to add the following line to the constructor of Server in wxmirra:

self.launchPatch(app,patch)

otherwise the patch won't start automatically. or did i get something wrong?

yes i did. I was confused by an error on linux that did not kill the chuck process. I am working now on the chuck side. I have a class that has functions that send the apropiate osc messages to the wx server. The wx server sends via osc messages so that chuck knows when it is time to define window properties and the widgets. I am a bit confused because the way Chuck works doesnt help organising the code, or probably i dont get how to do things properly yet. I would like to hide as much as possible from the end user into a server.ck file but it is pretty tricky. There is no include or import command (i am running "chuck server.ck example.ck" now), and on the other hand there is only one public class per file (oh well... i am too used to python...) I also managed to create standalone exe versions of the server that worked without needing python, wxpyton or simpleosc. The svn server is already up and running https://goto10.org/svn/ixi/python/wxmirra/ check out what i am up to and let me know how do you think it is. it would be great if you would add more widgets or anything else as well. When this initial step is solved, i will create a windows and mac standalone and upload it. Later i want to check swingOSC in Supercollider to see if i can get some ideas from there. enrike

altern wrote:

joerg piringer wrote:

...

altern wrote:

...

thor wrote:

...

...

right now in order to solve the problem of translating my patch i think maybe the easiest solution would be to use the pd GUI i already have to control chuck with OSC. Hey Enrike

You might consider using the SwingOSC

http://www.sciss.de/swingOSC/

- an OSC GUI server, originally made for SuperCollider, but I can't see any reason not to use it with ChucK.

(there are some PD (i.e. using SwingOSC with PD) examples in the distribution)

- This way you could even build one GUI and choose which soundengine to use or use many at the same time (ChucK, PD, SC, : ) of course. i forgot about this. I guess i could as well use wxpython with osc, maybe not that difficult for simple stuff like this. and there's OSCSurface: http://joerg.piringer.net/index.php?href=software/oscsurface.xml&mtitle=software i was thinking about translating it into wxPython, but i am not sure if i'll have the time to do it.

yes i remember this, but i am working on linux at the moment. Just wondering, how difficult would it be to create a ChucK wrap around a scaled down version of wxWidgets? just wrapping the widgets that are more likely to be used on a music project (sliders, buttons, some graphics to display waves...). A bit like what maui_gui is doing but as a module for the language without depending on the editor.

that would be great indeed! but as spencer points out concurrency could be the biggest problem. generally i would like to have the possibility to write externals as in PD. no need to alter the ChucK-code, just write a dynamic link library. i could think of many marvelous things to add this way: video rendering, UGens, text to speech, wiimote controller input, etc. best joerg -- http://joerg.piringer.net http://www.transacoustic-research.com http://www.iftaf.org http://www.vegetableorchestra.org/