[PD] Evolution UC-33 tools in RRADical CVS

Frank Barknecht fbar at footils.org
Sun Oct 31 00:02:49 CEST 2004


Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:

> Great!  This is exactly what I am trying to work on right now.  I am  
> working on a set of objects like this for all sorts of human interface  
> devices, including MIDI and USB devices.  I would like to all be  
> structured similarly so that once you know how to use one, it would be  
> very easy to use another.  Currently, there are many different objects  
> that do this stuff, and they all work in different ways.
> 
> So it would be ideal if there was a [uc-33] object that had no GUI  
> stuff, but just output the info from the device and took input and sent  
> it to the device.  Then the RRADical GUI stuff would be built on top of  
> that standard Pd object. 

This [uc-33] object already exists: It's called [ctlin] ;)

Seriously, although rrad.evo33 might look very complicated, it's
basically just a very thin wrapper around [ctlin], which prepends
settable OSC-strings in front of the cc-values. The rest is Gui and
housekeeping like a lot of state-saving for OSC-symbols, Midi-CC
configuration, visualization (for example, the currently moving CC
will let the corresponding OSC string flash green).

I see the main advantage of using something like rrad.evo here, in
that it allows to have a real control center for keeping track of and
editing routings "Human <-> (Sound) Engine". This is possible, because
RRADical uses the "single border crossing" concept realized through
the OSC inlet.

BTW: I used a printed hardcopy of the rrad.evo33-help.pd patch with my
active settings for a recent performance as a kind of score. 

> I have on worked with these midi devices a  little bit, so I am
> largely guessing at what all needs to happen.  Does  this make sense
> in terms of your experience?  Also, I was hoping to  generalize
> these devices a bit, with something like a [sliderbank]  object, so
> that people could write patches that used MIDI slider banks  without
> being totally depending on one model of slider bank.

Although the rrad.evo33 patch was done, because I needed something
like it for my device, I'm very interested on making this more
general. It already has midilearn, so it is possible to use it with
any device. Although the name "evo33" hints at my device, it will work
with other fader devices, too, and the name shouldn't fool anyone.

(I'm not sure currently, if I committed the now working scaling
function into CVS already, will do tomorrow, if not yet.)

The most simple thing - and simple is better most of the time - would
be to just delete the three vertical sliders and the managing stuff
for them, and then make a one-slider rrad.vsl2osc.pd patch out of them
(name is too long, though, better group 4 sliders into on patch.) This
is similar to the rrad.evo33b.pd patch I also did, which just handles
one midi toggle-button.

32 copies of those could then be arranged inside another abstraction
to make a 32 slider [sliderbank] very easily, analogous for 16-fader
boxes.

I probably wouldn't do this as graph on parent in the end, but make a
normal abstraction out of it, because that's quite a screenful and
normally I don't want to have this kind of monster as part of another
patch.


-- 
 Frank Barknecht                               _ ______footils.org__




More information about the Pd-list mailing list