[chuck-users] translating a pd patch to chuck

[altern]

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

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