[chuck-users] translating a pd patch to chuck
ssalazar at CS.Princeton.EDU
Thu Dec 28 06:31:37 EST 2006
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.
> 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.
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
More information about the chuck-users