General
Lemur Ableton Controller Overwrite Question
Started by CE9958 on .
Sign in or create an account to join the conversation.
Hey guys,
So I'm midi learning my Lemur templates in Ableton and I've run into a little problem. Basically on multiple pages of the same general Lemur project on my iPad, I have a button set up to turn on and off an auto-filter so as to cut the lows out of a kick then drop them back in. Basic Daft Punk dynamics stuff. The issue that I'm having however is that when I assign one button to the power button of the auto-filter on say page one of my Lemur project, then go to try to assign another button to that same power button but from another page, the second button overwrites the first button. Anyone have any ideas why this is/any way around it?
Thanks!
So I'm midi learning my Lemur templates in Ableton and I've run into a little problem. Basically on multiple pages of the same general Lemur project on my iPad, I have a button set up to turn on and off an auto-filter so as to cut the lows out of a kick then drop them back in. Basic Daft Punk dynamics stuff. The issue that I'm having however is that when I assign one button to the power button of the auto-filter on say page one of my Lemur project, then go to try to assign another button to that same power button but from another page, the second button overwrites the first button. Anyone have any ideas why this is/any way around it?
Thanks!
You don't have to map the button twice in Ableton. If you set the button on the second page to the same MIDI message as the one on the first page, they will both control the same parameter in Live.
*High Five*
Thanks bud!
Thanks bud!
You could also use an alias, which is cool for that sort of thing and saves memory no?
What do you mean by an alias?whatisvalis wrote:You could also use an alias, which is cool for that sort of thing and saves memory no?
I'm sure it's in the manual, but if you right click on an object, say a custom button, and choose create alias you get a copy of that object. The Alias is subject to any changes you make to the original, it's more efficient than duplicating an object on multiple pages.
"I'm sure it's in the manual"
Strange, but it isn't.
Strange, but it isn't.
Making an object "alias" is not mentioned ANYWHERE in the manual and I was, too, confused as to what actually the advantages are. I reckon it saves memory as essentially, it is the re-incarnation of the same object in other pages of the same project. To create an object's alias right click on it (windows) and you will find the relevant option. It appears that "aliases" also "follow" the original object properties and attributes (for example dimensions, etc etc) so if for example you change an object's height, the "alias" will too.
Yes, an alias is basically the same object as that which is aliased . . . essentially you're telling LemurOS to paint the same object multiple times (as opposed to making a copy and assigning the same attributes etc).
Think of them like symlinks in a filesystem - and indeed they behave MOSTLY as a symlink should, which is to say if you alter the original object in any way this is reflected in the alias. Up to and including deletion . . . so if you make heavy use of aliases it's a good idea to attach a label to the ACTUAL object while building your template to help prevent accidental deletion of perhaps a whole heap of carefully placed aliases.
Another addition to the wishlist for me would be a lock on the Actual while aliases for that object exist (again, like well-behaved symlinks) - or at the very least a warning.
Oh, and programmtic creation and placement of aliases - this and the ability to do the createobject thang, with scripts intact.
Think of them like symlinks in a filesystem - and indeed they behave MOSTLY as a symlink should, which is to say if you alter the original object in any way this is reflected in the alias. Up to and including deletion . . . so if you make heavy use of aliases it's a good idea to attach a label to the ACTUAL object while building your template to help prevent accidental deletion of perhaps a whole heap of carefully placed aliases.
Another addition to the wishlist for me would be a lock on the Actual while aliases for that object exist (again, like well-behaved symlinks) - or at the very least a warning.
Oh, and programmtic creation and placement of aliases - this and the ability to do the createobject thang, with scripts intact.