hey guys,
due to the lack of accurate timer callbacks in live pythons API, i am thinking about max4live. therefore i have some questions.
a) is the performance of max4live as good as the pythons one? i am doing really complex stuff in python, so would be good to know the upper end performance comparison. this is the most important question, because i am using all that remote scipts in my live act
b) is python really not supported anymore? is it going to die?
c) is it possible to do everything thats possible with python? i mean complex algorithms, or os stuff like file access, network stuff like udp (osc)
d) how is the max4live patch saved? in ascii mode? because i am using version controll for my script development, i and would like to used it also in future
thx in advance
martyn
max4live vs. python
-
monkeymoda
- Posts: 4
- Joined: Sun Feb 20, 2011 10:18 pm
Re: max4live vs. python
I can answer only about the lst one and some of the third. You can pretty much do about anything max can, so udp send and receive, osc, etc. yes. As far as complex algorithms, what you can code in js and using other max features yes. I'm not completely sure how it compares to python but it pretty much allows you to use the max editor to write whatever can be done in max. You can also run your patches in max runtime if you write them and save them as max patches. You just can't compile standalone max applications (versions that don't require a user to have max runtime installed).
Re: max4live vs. python
ah okay, so there is a way to compile the patches.. that sounds like it could be fast as python, because python is also just an interpreter programming language...
thx for the info!
thx for the info!
Re: max4live vs. python
just had a look into the demo, is that right, that max is 99% the same like pd (puredata)
Re: max4live vs. python
from wikipedia:
Pd is very similar in scope and design to Puckette's original Max program...
Re: max4live vs. python
okay 
any other information about q: a) and b)?
any other information about q: a) and b)?
Re: max4live vs. python
a)
yes. the python api access in live IS the live API that max has access to. in m4l you can also access the whole api efficiently from an algorithm point of view via javascript. and there is SQLite access. but you cannot make embedded remote scripts. you need python for that; although i could be wrong - i never used python in live.
(of course in m4l but not the live api you can deal with massive amounts of data very fast and efficiently). in max6 data access and manipulation is even better, and the javascript engine is much faster. it will probably be more friendly and compatible once live9 comes out.
b)
where did you hear this? ableton are hugely invested in python. i expect it will remain. i have not heard any news different to that.
c)
yes. and yes. possible to do all and a massive amount more. just through a different interface.
d)
just look around this forum and you'll see examples of the compressed JSON format. natively it is saved in human readable text (maybe json like still i think). many people successfully use git etc to deal with max libraries. cycling74 themselves use svn.
p.s. - max is a completely different beast to pd these days. the similarities are superficial only.
yes. the python api access in live IS the live API that max has access to. in m4l you can also access the whole api efficiently from an algorithm point of view via javascript. and there is SQLite access. but you cannot make embedded remote scripts. you need python for that; although i could be wrong - i never used python in live.
(of course in m4l but not the live api you can deal with massive amounts of data very fast and efficiently). in max6 data access and manipulation is even better, and the javascript engine is much faster. it will probably be more friendly and compatible once live9 comes out.
b)
where did you hear this? ableton are hugely invested in python. i expect it will remain. i have not heard any news different to that.
c)
yes. and yes. possible to do all and a massive amount more. just through a different interface.
d)
just look around this forum and you'll see examples of the compressed JSON format. natively it is saved in human readable text (maybe json like still i think). many people successfully use git etc to deal with max libraries. cycling74 themselves use svn.
p.s. - max is a completely different beast to pd these days. the similarities are superficial only.
3dot... wrote: in short.. we live in disappointing times..
Re: max4live vs. python
a) does that mean i can import python scripts in m4l? okay, sound good, any infos when max6 is planned? dont want to buy now if its just a step ahead.
b) i heard that statement from a dev at ableton during my interview, "its officially not supported"... but it seems that also max4live is based on some precompiled python scripts. so they cannot kick it too easily
c) i am a little bit concerned about the performance, right now i just dropped in about 10 max patches and my cpu meter is at 20%... what when i am going crazy like the python remote scripts... i am scared, i guess they would never work.
d) great!
thx a lot, now try to transfer my steq2.0 project to max.. and then report how the performance does...
b) i heard that statement from a dev at ableton during my interview, "its officially not supported"... but it seems that also max4live is based on some precompiled python scripts. so they cannot kick it too easily
c) i am a little bit concerned about the performance, right now i just dropped in about 10 max patches and my cpu meter is at 20%... what when i am going crazy like the python remote scripts... i am scared, i guess they would never work.
d) great!
thx a lot, now try to transfer my steq2.0 project to max.. and then report how the performance does...
Re: max4live vs. python
ah just one more question:
is there a way to kinda compile the m4l scripts. so that hey are not editable anymore but gain a performance boost?
is there a way to kinda compile the m4l scripts. so that hey are not editable anymore but gain a performance boost?
Re: max4live vs. python
@mlostekk, you seem to be confused. about 50% your fault, about 50% my fault. apologies.
i am no expert, but...
regarding (b):
what the dev meant is that, accessing the live api via the python integration in live is officially unsupported for end users, but it is possible. projects like clyphX are testament to what can be done, as are many others. the use of python in live is not about to diminish. whether or not they somehow 'lock' this ability to access it or not in the future is another question.
regarding (a):
no, you cannot access python in max. there is a third-party solution to use python in max via java (which is supported in max), but this is the language per se and has no relation to live's api. in max / m4l javascript can be used instead to control the environment itself, and access the live api. you can also access live api via max patching object. people call max a 'graphical programming language', but it is not really. it is a way to graphically connect bits of c-code (objects) together in a fast and easy and real time manner. why don't you spend some time with it and all the tutorials to find out more?
regarding (c):
the tradeoff of embedding such an environment inside live is that there is a cpu hit. but it should not be as much as you say you are getting. accessing and controlling the live api is just one of the many things that max in live does. and also regarding (a) again: i thought you were referring to the speed of the access to the live api between python access and m4l access - this is what is the same. you can control it with the same speed and accuracy, which is not great as it all happens in the low priority thread, although this is fine for most use scenarios. this is the same in live (python) as it is in m4l (max patching or javascript).
regarding compiling:
no, that is not what python or javascript or maxforlive are about. in max6 there are real time on the fly (JIT) compiling features called 'Gen' which are very cool, but they have nothing to do per se with max4live or the live api.
i am no expert, but...
regarding (b):
what the dev meant is that, accessing the live api via the python integration in live is officially unsupported for end users, but it is possible. projects like clyphX are testament to what can be done, as are many others. the use of python in live is not about to diminish. whether or not they somehow 'lock' this ability to access it or not in the future is another question.
regarding (a):
no, you cannot access python in max. there is a third-party solution to use python in max via java (which is supported in max), but this is the language per se and has no relation to live's api. in max / m4l javascript can be used instead to control the environment itself, and access the live api. you can also access live api via max patching object. people call max a 'graphical programming language', but it is not really. it is a way to graphically connect bits of c-code (objects) together in a fast and easy and real time manner. why don't you spend some time with it and all the tutorials to find out more?
regarding (c):
the tradeoff of embedding such an environment inside live is that there is a cpu hit. but it should not be as much as you say you are getting. accessing and controlling the live api is just one of the many things that max in live does. and also regarding (a) again: i thought you were referring to the speed of the access to the live api between python access and m4l access - this is what is the same. you can control it with the same speed and accuracy, which is not great as it all happens in the low priority thread, although this is fine for most use scenarios. this is the same in live (python) as it is in m4l (max patching or javascript).
regarding compiling:
no, that is not what python or javascript or maxforlive are about. in max6 there are real time on the fly (JIT) compiling features called 'Gen' which are very cool, but they have nothing to do per se with max4live or the live api.
3dot... wrote: in short.. we live in disappointing times..
Re: max4live vs. python
In particular you can build devices with accurate timing sync'd to Live (eg. LFOs, step sequencers).pid wrote:...accessing and controlling the live api is just one of the many things that max in live does.
Re: max4live vs. python
okay, seems to be like a "drag and drop programming language" 
have to get used to it as a coder, but its more like a "downgrade" to wont take too long. now trying to convert all of my python control surfaces to max4live within the 30days evaluation then i will check out if its worth buying.
have to get used to it as a coder, but its more like a "downgrade" to wont take too long. now trying to convert all of my python control surfaces to max4live within the 30days evaluation
then i will check out if its worth buying.Re: max4live vs. python
No reason to chuck all your old Python scripts. You can always communicate from m4l directly to Python via the control_surfaces hook in the API (I make extensive use of this in Monomodular and the stuff I've done for Livid). Also, don't think of it as a downgrade: even though it offers a simplistic approach to coding with its graphical environment, you can also use many other languages from within m4l/Max, including C, Java, and Javascript.
http://www.aumhaa.com for Monomod and other m4l goodies.
Re: max4live vs. python
really? also c???? would be awesome! any link to a tutorial or some examples how?
Re: max4live vs. python
The C stuff is pretty esoteric, but if you search the web you can find several examples of how to build and compile both C and Java externals. I compiled working versions of both my first C and Java externals the same day I started writing them, without having any background in either language.
Javascript is rampant, the cycling forums are probably the best place to start.
As to hooking into Control Surface scripts in Live (i.e. Python), there aren't really any good tutorials that I know of (but there probably are some that I don't know about!). You just have to pick apart the code if you want to do things the way I do them.
Darren Cowley's stuff is a good example, and well developed. It uses the conventional approach, and he uses the Live _Framework as it stands. I, on the other hand, run a lot of routines in Python, and hook to them through a ControlElement module, which allows me to send stuff back and forth as needed, but I do it all through Javascript. Certain things are just way faster in Python, so I do them there. I wouldn't start there ("walk before run", and all that). I'd get up to speed with the normal Max conventions first, all the visually-based elements, and then go from there. Hit me if you have specifics you want to know about, or take a look at Monomodular.
Regarding (d) above, I find version control to be a huge PITA with Max, but that's probably just me. The native files are xml based, I think, so its not so big of a problem. But frozen patches (the prefered way of distribution, and much simpler for inclusion of dependencies when working with others) tend to be a hassle, but allow inclusion of C externals and Javascript files by embedding them in the patch.
a
Javascript is rampant, the cycling forums are probably the best place to start.
As to hooking into Control Surface scripts in Live (i.e. Python), there aren't really any good tutorials that I know of (but there probably are some that I don't know about!). You just have to pick apart the code if you want to do things the way I do them.
Darren Cowley's stuff is a good example, and well developed. It uses the conventional approach, and he uses the Live _Framework as it stands. I, on the other hand, run a lot of routines in Python, and hook to them through a ControlElement module, which allows me to send stuff back and forth as needed, but I do it all through Javascript. Certain things are just way faster in Python, so I do them there. I wouldn't start there ("walk before run", and all that). I'd get up to speed with the normal Max conventions first, all the visually-based elements, and then go from there. Hit me if you have specifics you want to know about, or take a look at Monomodular.
Regarding (d) above, I find version control to be a huge PITA with Max, but that's probably just me. The native files are xml based, I think, so its not so big of a problem. But frozen patches (the prefered way of distribution, and much simpler for inclusion of dependencies when working with others) tend to be a hassle, but allow inclusion of C externals and Javascript files by embedding them in the patch.
a
http://www.aumhaa.com for Monomod and other m4l goodies.