Hallo, patrick hat gesagt: // patrick wrote:

i'm allready using > rrad.evo33.pd and rrad.evo33b.pd, but rrad.evo33b.pd don't have state saving in it (preset)? maybe i'm wrong...

the thing with this solution is i have to type all my commun in a symbol object of pure data. and i think everybody agree that it's not really fun to type /channel1/out/panning_left etc... in the small symbol object + no copy & paste, and no correction (it erase everything if you need to edit part of the string).

so that's why i was asking if it's possible to still use rrad.evo33.pd, but not type OSC target, but just touch the target (can be slider, number etc...) that you want to map?

Hm, sounds like an interesting idea. What exactly does "touching" mean, is it just moving the slider a bit?

This then could be made to work by watching the OSC-outlet's output and storing the currently sent key automatically. Kind of like a [rrad.osclearn] ;)

Ciao

Frank Barknecht _ ______footils.org_ __goto10.org__

I have a (non-rradical, but could be modified if you take the time) little patch to do the touch assign thing. You just click the toggle, and then move your slider or knob, then release the toggle, and it's assigned. But it's currently non-saveable. Take a look, and please offer any hints/suggestions.

On another note, I've searched the archives and google, but cannot find a place to download this pixel tango, and I really want to try it out. Where can it be found?

~Kyle

On 10/26/05, patrick patrick@11h11.com wrote:

hi frank,

i'm allready using > rrad.evo33.pd and rrad.evo33b.pd, but rrad.evo33b.pd don't have state saving in it (preset)? maybe i'm wrong...

the thing with this solution is i have to type all my commun in a symbol object of pure data. and i think everybody agree that it's not really fun to type /channel1/out/panning_left etc... in the small symbol object + no copy & paste, and no correction (it erase everything if you need to edit part of the string).

so that's why i was asking if it's possible to still use rrad.evo33.pd, but not type OSC target, but just touch the target (can be slider, number etc...) that you want to map?

pat

----- Original Message ----- From: "Frank Barknecht" fbar@footils.org To: pd-list@iem.at Sent: Wednesday, October 26, 2005 8:44 AM Subject: Re: [PD] pixeltango nice feature not tested

...

Hallo, patrick hat gesagt: // patrick wrote:

...

in pixeltango there's a nice feature. if you touch a [commun] object you can assign a midi controller to it. i didn't test it, but i think it's there. for an example:

1. you touch rotate_x slider
2. you turn a know on your controller
3. the rotate_x is assign to the last cc
4. you save this routing

it would be great to have this kind of template in memento!

There is "rradical/control/rrad.ctlearn.pd" in RRADical which you could use to wrap the [communs] you'd like to be midi controllable. I don't want to add this directly to [commun] as [commun] also can be used to state-save non-floats like lists and symbols.

Alternatively I personally prefer to use a seperate patch to interface with midi altogether. In CVS you can find this approach realized in: rrad.evo33.pd and rrad.evo33b.pd

They work as a kind of general purpose mapper from midi-CC to arbitrary OSC messages with scaling of value ranges. All settings are saved into a memento as well. This way you can create different CC-OSC-mapping groups, that you can change on the fly. This is veryvery powerful, much more so than a direct CC-to-slider-mapping could be. However I agree, that it requires a bit more planning, though.

Ciao

Frank Barknecht _ ______footils.org_ __goto10.org__

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

-- http://perhapsidid.blogspot.com (((())))(()()((((((((()())))()(((((((())()()())()))) (())))))(()))))))))))))(((((((((((()()))))))))((()))) ))(((((((((((())))())))))))))))))))__________ _____())))))(((((((((((((()))))))))))_______ ((((((())))))))))))((((((((000)))oOOOOOO

Hey all,

Well I'm back from Norway and pretty well though my email. (600 messages this time!)

Anyhow Patrick for the record this "feature" is not implimented, and it was always my intension that this should be integrated into the rradical/memento thing, with Frank's help.

So I'll outline my vision first and then talk about the way the architecture could work.

From the user perspective:

1. The user loads a pixelTANGO (actually the idea is any memento) patch.

2. An abstraction (or second patch) is loaded to wich you send a message

like: [midi table<

3. The abstraction creates a new sub-window that contains a dynamically

generated array of GOP abstractions, each looking something like:

/pt/layer/1/pt.fader/a [ ] On/Off [X] Learn [0 \ CC [0 \ Channel

On and off just turns on and off a spigot to disable/enable routing to that OSC name, Learn turns on the latching stuff to associate that OSC name with a controller/channel.

One of these is generated for every memento'ed parameter in the patch. (yes it could be a really long list)

And the channel/cc are saved based on the OSC name so that you could load an old state after your patch has changed and the mappings still work.

4. The user goes through each parameter turning on "learn" and then

moving a slider/fader to associate each OSC name to the MIDI CC

Possible Architecture:

Frank was/is (still?) planning on the idea of a central pool that stores not only the state of the commun objects, but also creates a list of all of them in a patch. (well I think Frank wanted to do this per abstraction). I would also like the OSC name to be pulled into this pool.

This table would be something like:

index OSC-name

perhaps..

Of course if one deleted an abstraction in the patch then we would need to re-generate this list... I guess a signal that queries all the communs and resets that directory in the pool. Frank, I think your prototype did do this.

Then the mapping abstraction takes care of reading the table and generating the array of abstractions.

Then each abstraction simply latches its CC/channel data and sends it to the OSC target.

Problems/Issues:

Frank already mentioned the issue around non-float messages and MIDI mapping. Perhaps the pool that collects the communs would have a freild for the data type, and a MIDI mapping abstraction would only be created for each float type... Or floats are kept seperate from the Lists and Symbols... Thinking aloud here.

I have not thought much about the numeric range thing, maybe all MIDI controllers are automatically ranged to 0-100 floats and then all parameters expect the 0-100 range.

OSC control is broken in pixelTANGO. This is due to the programatic limits of OSCx (OSCroute actually). For pixelTANGO the user does not define the OSC name of a parameter, this is defined by the module itself. So it is not an argument to the abstraction but generated dynamically. To do this we need to be able to set the OSC route name by message, rather than by argument. (This is not really an MIDI mapper issue)

The general purpose OSC Mapper:

So after all this effort we can map MIDI controllers onto arbitrary OSC names in any memento/RRADical patch. nice. But what I really want is to be able to use this for general bulk control, not just MIDI. That means:

LFO bank uses the same system to automate parameters (but this would require a way of turning on and off certain commun objects from state-saving, and to avoid conflicts with MIDI controllers etc..)

Also crazy things like feeding an RSS feed into the symbol [commun] objects would be very cool.

Ok so thats my statement to date...

Frank, care to get back into the discussion, I have not had a chance to look at the patches you mention in this thread yet, I would really like to work with you on this to have an integrated system that can be used for any RRADICAL/memento patch...

.b.

Frank Barknecht wrote:

Hallo, patrick hat gesagt: // patrick wrote:

...

in pixeltango there's a nice feature. if you touch a [commun] object you can assign a midi controller to it. i didn't test it, but i think it's there. for an example:

1. you touch rotate_x slider
2. you turn a know on your controller
3. the rotate_x is assign to the last cc
4. you save this routing

it would be great to have this kind of template in memento!

There is "rradical/control/rrad.ctlearn.pd" in RRADical which you could use to wrap the [communs] you'd like to be midi controllable. I don't want to add this directly to [commun] as [commun] also can be used to state-save non-floats like lists and symbols.

Alternatively I personally prefer to use a seperate patch to interface with midi altogether. In CVS you can find this approach realized in: rrad.evo33.pd and rrad.evo33b.pd

They work as a kind of general purpose mapper from midi-CC to arbitrary OSC messages with scaling of value ranges. All settings are saved into a memento as well. This way you can create different CC-OSC-mapping groups, that you can change on the fly. This is veryvery powerful, much more so than a direct CC-to-slider-mapping could be. However I agree, that it requires a bit more planning, though.

Ciao