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.