[chuck-users] translating a pd patch to chuck
altern2 at gmail.com
Mon Jan 1 16:00:47 EST 2007
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
>>>>>> 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
>>>> for simple stuff like this.
>>> and there's OSCSurface:
>>> 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
>> 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
>> 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.
More information about the chuck-users