Ableton Forum

thanks for dropping that Robert, this comes up often.

henke wrote:makes sense. but here is where the problem starts. 99% of all users are happy with how it is. for some there would be something like a random function which is tied to something else. but here the problem starts: tied to what? song time ? clip time ? the same for all instances ?
etc.. etc... this is where M4L comes in the game quite handy. Users can find individual solutions for their purposes without the need to think about every potential use-case. You build something that works for you for your project and if it does not work for the next project you'll build a slightly different version. If 'predictable' random would be implemented in all devices that deal with random in Live and it should serve all possible purposes this would be a huge task. Now explain someone why we should do this instead say... curved automations... or what ever is on the list of things to do for future versions...
Robert

99% were you getting that statistic from? I think your looking into it way too deep. Its not tied to anything I simply ment each midi note has a random velocity from a button or drop down menu.

Using M4L as a solution seems abit like using a shotgun to kill an ant...

Probably not the place for it but since there's a discussion on it:

Can Max for Live be used to create global variables?

Like, could I make a plugin that goes on Master that would change every Pitch/Transpose control in every clip/on every track by the same amount?

So I could have a store of clips that I could pull into my set, but have it so that each one would have an offset value (say, relative to C) so I could make sure everything was in key, but could be put in different keys?

So, like, I have an audio clip in E (offset -4), an audio clip in C (offset 0), and a MIDI device for a clip in A major (offset +3) - could I have it so that if I were jamming in C and wanted to modulate everything up to D, it could change the E offset to -2, the C offset to 2, and the A offset to +5?

To get back on track I'd also back Abletons reverb, it just works for me.

thanks for answers robert.

TBH, i would need to dive into MFL deeper, but im too much in love with usine.
(i wish there was an usine4Live rather than MFL), but maybe OSC will come out to access those sexy new links to internal datas.

as an exemple of above 'fears', im personnaly affraid OSC will be bypassed in favor to MFL. and osc being dealed exclusively with max.
that understandable as less work for ableton, but for users and openess it would be less cool..
hope im wrong.

anyway ot now.. but thanks, your communication is apprecied, and im pretty confident the benefits of the huge, long,pain work
of openness of live to modular will shine more and more with time.

8TROW8 wrote:

henke wrote:makes sense. but here is where the problem starts. 99% of all users are happy with how it is. for some there would be something like a random function which is tied to something else. but here the problem starts: tied to what? song time ? clip time ? the same for all instances ?
etc.. etc... this is where M4L comes in the game quite handy. Users can find individual solutions for their purposes without the need to think about every potential use-case. You build something that works for you for your project and if it does not work for the next project you'll build a slightly different version. If 'predictable' random would be implemented in all devices that deal with random in Live and it should serve all possible purposes this would be a huge task. Now explain someone why we should do this instead say... curved automations... or what ever is on the list of things to do for future versions...
Robert

99% were you getting that statistic from? I think your looking into it way too deep. Its not tied to anything I simply ment each midi note has a random velocity from a button or drop down menu.

Using M4L as a solution seems abit like using a shotgun to kill an ant...

Ah, I got it. Well, I am afraid I have to look deep here: The MIDI editor is not exactly luxury in its current state. Simply adding a "randomize note velocities" menu entry would be a very arbitrary enhancement. Why not add a "reverse notes" "fixed length" etc... command? You do all this and end up with a feature that should be better a full blown MIDI note transformer thing, because the list can be very long and demands much more than just a pulldown menu. You might want to type in values, store settings for later usage, etc.. It is a big feature. And it should still be Ableton style, interface wise: no floating window, etc.. etc.. things start getting highly complicated if you look closer. Given this I would think a MAX patch which does interesting random variations of notes is the much better choice. Because if you do not like it, just don't install the patch or modify it. Once a feature has been implemented in Live itself it can never ever be removed. There is a huge danger here in making things complicated and ugly.
Therefor I disagree. A Max Device that randomizes notes and can be modified and discussed till it really fits your needs is actually using a surgeons knife for a highly specialized task. Ten people will post a randomizer. The best one will be the one everyone is using at some point. Some ideas: randomize only offbeat notes, randomize only notes under a certain velocity, apply randomization again and again every eight bars. create a 64 bar version with randomized off beat velocities out of a 1 bar loop. This is where MAX is the ultimate tool for.

Robert

Thanks man.

Feature request: You posting here alot

henke wrote: Once a feature has been implemented in Live itself it can never ever be removed.

QFT

henke wrote:Simply adding a "randomize note velocities" menu entry would be a very arbitrary enhancement.

But it would be an enhancement just as you said and as I originally suggested, right?

Rome wasn't built in a day.

agent314 wrote:Probably not the place for it but since there's a discussion on it:

Can Max for Live be used to create global variables?

Like, could I make a plugin that goes on Master that would change every Pitch/Transpose control in every clip/on every track by the same amount?

So I could have a store of clips that I could pull into my set, but have it so that each one would have an offset value (say, relative to C) so I could make sure everything was in key, but could be put in different keys?

So, like, I have an audio clip in E (offset -4), an audio clip in C (offset 0), and a MIDI device for a clip in A major (offset +3) - could I have it so that if I were jamming in C and wanted to modulate everything up to D, it could change the E offset to -2, the C offset to 2, and the A offset to +5?

Yeah. Doesn't sound too hard either. It would essentially be a global pitch plugin.
All it needs to do is send + 3 to be added to whatever value Transpose is at right now.
Would work with Audio Clips and MIDI Tracks that have a pitch plugin.

fx23 wrote:thanks for answers robert.

TBH, i would need to dive into MFL deeper, but im too much in love with usine.
(i wish there was an usine4Live rather than MFL), but maybe OSC will come out to access those sexy new links to internal datas.

as an exemple of above 'fears', im personnaly affraid OSC will be bypassed in favor to MFL. and osc being dealed exclusively with max.
that understandable as less work for ableton, but for users and openess it would be less cool..
hope im wrong.

anyway ot now.. but thanks, your communication is apprecied, and im pretty confident the benefits of the huge, long,pain work
of openness of live to modular will shine more and more with time.

As ST8 and the other python guys have already proven with LiveOSC. The only thing standing between us and Native OSC support is a python developer.

http://www.ableton.com/jobs/python-developer

If anything, Max For Live will (and already has) add improvements that can be used with python scripts. Access to devices inside Racks is an example.

yup right hoff, but im really affraid ST8 is really busy with liine team now...
and sadly there are not many people with such knowledge and willing to share actually, at least on the OSC side.
LiveOSC would need some refresh, and native OSC would as you point ideally need a permanent python dev.
Hope they ll find a python dev, but if still searching, that mean we can wait OSC for long...
what, there aren't any python dev that wanna work for abes? or not enough experienced?
(hey abes, if so please engage ST8, give him tons of cash, he ll make killer osc in 2 weeks )

Live OSC could access nearly all API datas like MFL do, just in a less user friendly way,
still totally usable with millions of applications. actually it can't access device inside subracks, but
im pretty sure some master like ST8 could upd/hack that in few days, not to say few hours.
it's just write/read/ to an API path after all,no?
ive myself implemented the recent tracks colors, nudge, metronome and various other stuff.
it took me a while cause im a total noob in python, but a python user would have done that in 5mn, really.
Hard to see why this isn't possible yet, there is surely some people that know python in ableton hq, that's a matter of putting time and ressources for that. Maybe they are just two on APC or other, but if so that's really sad.
they really need to find python devs.

Many major audio/video softs and especially modular ones got OSC now. few hardware and futur ones are osc too.
Midi is cool but it's outdated, especially to transfert all the fancy differents variables live can offer.
Live API could be accessed with max, usine, pd, lemur, arduino, linked to VJ softs, whatever, that would be soooo lovelly..
it has been requested from a while now, maybe before M4L was even imagined..
so.. i do hope all the layers that has been engaged to link to Max will be re-usable for
that futur potential (never coming) 'native osc'.

fx23 wrote:Live API could be accessed with max, usine, pd, lemur, arduino, linked to VJ softs, whatever, that would be soooo lovelly..
it has been requested from a while now, maybe before M4L was even imagined..
so.. i do hope all the layers that has been engaged to link to Max will be re-usable for
that futur potential (never coming) 'native osc'.

Right, but there isn't an OSC standard that works for everybody. And there are a bunch of hard design decisions to make when designing OSC support. Like how do you deal with multiple OSC devices/IP's, what is the most user-friendly way for a user to connect to a device, how do you deal with the PC users who aren't keen on installing Quicktime (they really love that) to provide nice Bonjour connection support, etc..

Its not just a matter of hooking things up and being able to query info from Live.
This is where MFL comes in handy. Instead of routing OSC to an application to do something with the OSC, you do it in Live and if you still need an OSC output you just add it.

Currently we already have support for Arduino and the likes. You can wire a Step Sequencer up to Arduino and use it to control a modular synth. You can feed signals to Quartz Composer and all the other VJ softwares. You can even add support for pretty much every protocol known to man.

Its just a choice you have to make. Do you wait for Native OSC support and hope it includes everything you wanted. To then manipulate that OSC signal in another application and hope Live likes the signal it gets back? Or do you want to play with your idea tomorrow?
A thing like LiveControl can be built in MFL in less than 100 hours. Of which like 50% of that time goes to typing OSC names in the TouchOSC editor. And this was before Ableton improved the API. It should go even faster today.

I know you really like Usine. But at some point you'll have to accept that it'll be 10 times more powerful when combined with Max. And once you realize how fast things go inside Live, you may prefer to do some function inside the application instead. Pretty much everything sequencing related can not match up against MFL sequencers and their 1ms delay that is automatically compensated by Live like all the other Native MIDI plugins.

in the softs i use osc is just dealed via one IP or host name and that just works, nothing really hard to implement imo.
Multiples devices could come later, in 90 percent of cases man will use just one osc device.
however it's true there are multiples scenarios possibles in what whould be implemented, but
for me it would be a pure translation of API paths get/set/observe to osc, to avoid those multiples scenarios,
that would be dealed outside in the other app. OSC would just link receive/deliver the datas with all the rounding,ranges and
datatypes protections checks that are certainly a bit of work but not that hard to do.
integer,single,string,boolean,array,min,max,size what else?

but you got the real point. i should probably just shut my mouth, buy MFL and start to do the stuff wich is already
available. I know you are right, and it's the way,and it will be maybe painless and powerfull.
But yes, it's really, really hard for me to go back to max i tried in the past while i know and start to master usine wich i find 10x more sexy and fun to use every day, and wich is multitouch ready from a while, with touchscreens performances setups and modularity in some areas that max itself can't match actually i would really miss.

but well, i know I won't resist against the empire for long..

8TROW8 wrote:But it would be an enhancement just as you said and as I originally suggested, right?

Rome wasn't built in a day.

You completely missed his point. People are using Live instead of Reaper or Cubase or Logic or what have you because it has a small, well-chosen feature set. Well, you can argue about how well-chosen it is for your needs, but the point is there is not and never will be a separate dialog box that has got 35 buttons, two pulldown menus and a sub-dialog with a couple more checkboxes, another pulldown, and a couple other fields: all just for setting up how recording automation behaves. (That's Cubase, if you're not familiar with it)

Similarly, the chance of you ever seeing a velocity randomization parameter in Live proper is 0. The number of people who would use the feature is relatively small, it's usually easily done in the plugin instead, and good implementation requires lots of options and knobs and sliders and checkboxes, which is the exact opposite of what Live is all about.

I should clarify that by Live proper I mean on the pianoroll interface itself. Of course you can build it today in M4L if you want, you can go download Tobybear's Humanisator today if you are on a PC, perhaps in some distant dystopian future you will see it in an built in Live plugin - but I wouldn't hold your breath.