[PD] pixeltango nice feature not tested

[B. Bogart]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20051029/639f99b2/attachment.pgp>