Clip Mapper 1.0

[hoffman2k]

Many thanks for sharing this patch it is really useful.

Any chance of an option to save the parameter values along with the parameters?

So if for example I have the clip mapper set up for the same parameters for 2 different clips I can have independent parameter values?

Obviously I should patch this myself if I want it - not much experience with the pattr objects (so be a good opportunity to learn!)

Can you give me any tips. I guess I just need to find the bit where it saves the paramater names and add a bit to save the values.

Then find the bit where it loads the saved parameters and load and set the value as well.

Cant find there "s ---knob1 sends" too though!

There are some objects in there that still need to be cleaned up from earlier versions, like those sends. I'll comment and clean the patch some more for a later version. My main priority here was getting it to work, because as far as I am aware, not many people are using pattr like this yet.

I'm on board with your value saving idea, I originally made a Max app called Snapshot Matrix for such things. I currently have no time to build such a thing though. But some parts are already in place. I'll make a tread later to share some individual components of this patch.

For example, I'm using Coll to store the paths of the parameters along with the ID's. But the path is linked to an ID number, it isn't a value. Leaving room for the parameter value.
Then comes the matter of parsing it into pattr data and getting it back when the set loads.
I'm by no means an expert in this stuff, it all came together after a lot of trial and error.

[gavspav]

I've made a patch that stores incoming midi control values in a coll according to which clip is playing and then sends them out via midi yoke.
At the same time it recalls the values when a new clip is triggered and sends those out too.

It works but theres still a few bugs and your clip mapper has extra functionality and looks all nice.

Mine is simple and dirty, based on midi routing - probably not the best way of doing things. Its not tidy but it is here if it helps:

http://pastie.org/837614.txt

[hoffman2k]

I've made a patch that stores incoming midi control values in a coll according to which clip is playing and then sends them out via midi yoke.
At the same time it recalls the values when a new clip is triggered and sends those out too.

It works but theres still a few bugs and your clip mapper has extra functionality and looks all nice.

Mine is simple and dirty, based on midi routing - probably not the best way of doing things. Its not tidy but it is here if it helps:

http://pastie.org/837614.txt

Cheers. A little too dirty for me, but then again.. I usually only understand patches after reverse engineering them. I even had to rebuild some of these API abstractions to really understand it enough to use in the Clip Mapper.

[gavspav]

I've been playing around with my saving parameter values patch today and have realized that there will always be a short delay between a clip being triggered and the m4l device getting the parameter values out of the coll and applying them.

I've tried to optimized my patch - using live.remote~ now to control the parameters.
Still getting the data in from the controlller via midi though - wouldn't have thought the api would be quicker?

I guess I could delay the triggering of a new clip until the effects have been set eg by muting the volume but this seems a shame.

The delay is ridiculously small by the way and you can only really hear it if you trigger a clip when nothing else is playing and even then only sometimes!

[S4racen]

Ok, the patch is brillant, it does seem a little twitchy though.... I've mapped 8 clip stop buttons to fire different sends on each track (the send only effects the track in view) these also fire the clips that are identified by the clip mapper corresponding to the send in question eg. i send track A to send A and the clip mapper maps my knobs (send a bank on the APC40) to control the device on send A.....

This works well but it would seem that repeated presses of the clip stop button make the values of the device in send A change and in fact when moving between devices it would appear that values are being taken from one device and used on the next device?

Apart from that (as i'm using it for delays and the like) the way it works is superb so it's now a mainstay of my patch and works as a floating window....

Cheers
D

[hoffman2k]

Ok, the patch is brillant, it does seem a little twitchy though.... I've mapped 8 clip stop buttons to fire different sends on each track (the send only effects the track in view) these also fire the clips that are identified by the clip mapper corresponding to the send in question eg. i send track A to send A and the clip mapper maps my knobs (send a bank on the APC40) to control the device on send A.....

This works well but it would seem that repeated presses of the clip stop button make the values of the device in send A change and in fact when moving between devices it would appear that values are being taken from one device and used on the next device?

Apart from that (as i'm using it for delays and the like) the way it works is superb so it's now a mainstay of my patch and works as a floating window....

Cheers
D

It sounds like an order problem. Something getting a bang too quick.
I haven't run into the issue myself, but I'll keep an eye out for it.
If you can reproduce it easily, please send me a small set. It probably wouldn't hurt to see if one can actually load that data from another user. Haven't exactly tested that yet.
Another problem may be the use of other API based devices, but I can't see how.

[chapelier fou]

Just saw the video and realized the power of this patch. This deserves to be a full fonctionnality of future versions of live. Thank you very much for this, it is really brilliant !

[hoffman2k]

Cheers Chapeller!

A new update (0.9.7): http://covops.dreamhosters.com/uploads/ ... 7.amxd.zip

- You can now use multiple instances anywhere (Audio Version coming)

- Cleaned up most redundant stuff and debugging mess.

This version is not compatible with data stored in previous versions. I expect this is the last time I need to do this. All future updates should remain compatible.

[concrete_cow]

Cheers Chapeller!

A new update (0.9.7): http://covops.dreamhosters.com/uploads/ ... 7.amxd.zip

- You can now use multiple instances anywhere (Audio Version coming)

- Cleaned up most redundant stuff and debugging mess.

This version is not compatible with data stored in previous versions. I expect this is the last time I need to do this. All future updates should remain compatible.

Fantastic Bjorn. Looking forward to testing. I've been having the same problem as Darren, in that when changing settings using different clips, i'm finding that the previous device's values are copied across. It happens only on occasion, but too frequently to be useable (probably around 1 in 6-7 clip switches).

I'm happy to send you my set if you think it'll help you debug? That is, unless you think it's been fixed in your new release?

Thanks again mate, really happy with what you've made here
Sunil

[hoffman2k]

Cheers Chapeller!

A new update (0.9.7): http://covops.dreamhosters.com/uploads/ ... 7.amxd.zip

- You can now use multiple instances anywhere (Audio Version coming)

- Cleaned up most redundant stuff and debugging mess.

This version is not compatible with data stored in previous versions. I expect this is the last time I need to do this. All future updates should remain compatible.

Fantastic Bjorn. Looking forward to testing. I've been having the same problem as Darren, in that when changing settings using different clips, i'm finding that the previous device's values are copied across. It happens only on occasion, but too frequently to be useable (probably around 1 in 6-7 clip switches).

I'm happy to send you my set if you think it'll help you debug? That is, unless you think it's been fixed in your new release?

Thanks again mate, really happy with what you've made here
Sunil

I haven't fixed this specific issue as I have yet to identify the cause, so a set along with some instructions would be useful. You can send it to b[at]covops.org. I probably don't need the samples used in the set.
However, if you're mapping to VST's. Check if that is a factor. As I most likely do not have those plugins to reproduce it here (if plugins are involved in any way).

[concrete_cow]

Sure, i'll forward over a copy of my set later tonight. There are a number of plugins being used, but they are mainly VST's loaded into live racks. I assume that if you don't have the plugins, the clip mapper will still map to the racks?

Also, forgot to ask before... but does max feature a way to create 'blank' mapping for the knobs/buttons in the clip mapper? E,g. some of my clip mappings don't use all 8 knobs/buttons and i'm finding that if I don't specifically map all 8 knobs/buttons, then the unmapped knobs/buttons inherit the previous clip's mappings. Thus a 'blank' or null mapping would be excellent to avoid confusion and mis-mangling! What do you think?

[hoffman2k]

Sure, i'll forward over a copy of my set later tonight. There are a number of plugins being used, but they are mainly VST's loaded into live racks. I assume that if you don't have the plugins, the clip mapper will still map to the racks?

Also, forgot to ask before... but does max feature a way to create 'blank' mapping for the knobs/buttons in the clip mapper? E,g. some of my clip mappings don't use all 8 knobs/buttons and i'm finding that if I don't specifically map all 8 knobs/buttons, then the unmapped knobs/buttons inherit the previous clip's mappings. Thus a 'blank' or null mapping would be excellent to avoid confusion and mis-mangling! What do you think?

Yeah, I agree. I hadn't added such a thing yet because I'm not sure a clear button on the interface is the smartest thing. But one option I'm considering is holding a modifier while pressing the Learn button to enable a blank slate. The upside to having the blank slate to start from is that you can combine groups.
For example if you have 16 parameters on clip 1 and 4 parameters on clip 2, triggering clip 1 and then clip 2 will result in a combination of the 4 parameters and 12 of the 16 previous ones.

[concrete_cow]

Any idea what i'm doing wrong with this patch? Trying to convert 0.9.7 to an audio plugin. Have added an max audio device to the master channel, copied the contents of your patch across. When I click Presentation in the max patch window, I see what i would expect, but after saving it and closing the max window the patch shows the plugin in/out bit only ? Apols for my nubishness lol!!

http://dl.dropbox.com/u/121914/ClipMapper0.9.7.amxd

Wanted to test to see if i had the same problem with the new patch before asking you to bug test my set...

Thanks!
Sunil

[concrete_cow]

Bjorn,

Just tested 0.9.7. It's MASSIVELY quicker than 0.96! The debug code removal has worked wonders on the responsiveness. Its almost instant to change between clips and i've not seen the same problem as before where the previous device values are copied over... maybe as per your post to Darren before, the bang was being send too fast or being delayed? I've not finished setting up my mappings, but will test once you've been kind enough to help out with the audio version so I can rebuild everything

[S4racen]

Great news, when this works it's fvcking incredible, i've changed the way it recalls the presets on mine so that it will only fire if the clip has changed and not if im triggering the same clip again......

Cheers
D