Spencer Salazar wrote:
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
- 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.
yes but it would be great to have something like that. big effort maybe.
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.
that sounds more like something i could try to do. I am currently working a little bit with wxpython for another project, so I might have a go at some tests in this direction. It might be a good practice as well. enrike