Could it be because the time was spent on giving solid access to the API? I imagine that once that was done along with the other development they didn't have much of an idea of how we would use it and so the support has been there from day one on the cycling forum to help with anything we wanted to create....
I'm not saying there should have been more (control surfaces anyone!) but i imagine getting a product out for us to create with was the priority over reams of preconfigured devices that may or may not have any tangible use to the community?
Cheers
D
poor API showcase?
Re: poor API showcase?
I don't really think its a decision. Its more a matter of how much a handful of people can actually build within a years time. How many people understand the API stuff and make Max patches?
I can see the .maxpat examples being a mistake though. Not much use to a non Max user. Although you can copy/paste a maxpat into a device, but thats just opening a can of worms...
Anything specific you want to do with the API? Because figuring that out is pretty much the most important thing. Even if there were a patch that does something similar to what you wish for, it'll never be EXACTLY what you want. That is where the community comes in.
I get your point of wanting to see loads of cool API based devices. But speaking as somebody who built a few, these aren't the types of devices you whip up in a day. And in my case that is even with prior knowledge of how the API works from the unofficial hacks.
And my personal opinion is that this is far from finished. Currently the API just has access to the features that all the remote control surfaces combined can access (apart from sample accurate control). Once Ableton gets their crap sorted, we should start seeing some API features that are actually built to do specific things in M4L. Like adding/deleting clips for example.
The reaktor library wasn't built in a day
I can see the .maxpat examples being a mistake though. Not much use to a non Max user. Although you can copy/paste a maxpat into a device, but thats just opening a can of worms...
Anything specific you want to do with the API? Because figuring that out is pretty much the most important thing. Even if there were a patch that does something similar to what you wish for, it'll never be EXACTLY what you want. That is where the community comes in.
I get your point of wanting to see loads of cool API based devices. But speaking as somebody who built a few, these aren't the types of devices you whip up in a day. And in my case that is even with prior knowledge of how the API works from the unofficial hacks.
And my personal opinion is that this is far from finished. Currently the API just has access to the features that all the remote control surfaces combined can access (apart from sample accurate control). Once Ableton gets their crap sorted, we should start seeing some API features that are actually built to do specific things in M4L. Like adding/deleting clips for example.
The reaktor library wasn't built in a day
Re: poor API showcase?
the same could be said about the 30 or so audio pluggo effects.. however, if 90% of a device does what I need, hacking together the remaining 10% is very doable..hoffman2k wrote:Even if there were a patch that does something similar to what you wish for, it'll never be EXACTLY what you want. That is where the community comes in.
but there at least has to be 90% present.. that's why I started this thread in the first place..
though this is not about wanting to have devices which I can cut up and reuse per se, this is about devices I can immediately use and give some ideas about what the API can be used for..
I bet there are a few masterminds at C74 HQ who can..But speaking as somebody who built a few, these aren't the types of devices you whip up in a day.
true.. but at least every other update showcases Reaktor as broad as possible.. can't say that about MFL..The reaktor library wasn't built in a day
and I can't say I'm flabbergasted by the current MFL community outcome.. not judging, just noticing..
mind you, as you can probably tell, I'm not a Max builder..
I invested too much time already in learning Reaktor so I can't afford to also thoroughly learn Max..
so providing a folder with 40 .maxpat API building bricks is not what I want really..
I wanted a couple of full blown devices which immediately show me what/where/when/how the API can be used..
from there on I could hack up those devices to my needs or get inspired to take derivative routes..
Re: poor API showcase?
Most of the work has gone into actually getting this working. And depending on wetter M4L is at fault for Live's current stability issues, both companies may be knee deep in code as we speak.
You're right. There is a huge lack of API examples and documentation. But you can't just dismiss a years worth of documents and examples so far. If anything, it only proves that in time all these building blocks will make it easier to actually whip up a device in a short time.
I also agree there aren't a lot of inspiring devices. But why should the inspiration come from within Max or Live. If almost anything is possible, it might suit you well to look outside the box and just come up with what you want and seek inspiration everywhere.
How would one go about making an "inspiring" device anyway? I can feel another reaktor comment coming up, but reaktor never felt right with me personally. Apart from the Skrewell patch, but that only inspired me to put a scope behind a randomized synth. Didn't even need to build anything, Daniel from Ableton took care of that on extendlive.com .
Anyway, I'm obviously not going to convince you and I'm definitely biased. If more devices and examples is what you want, patience is what you'll need. Maybe this thread might speed things up.
Its just a difference in our thinking I suppose. In reaktor people are used to endlessly browsing synths and sounds. In Max people are used to getting exactly what they want. And if it can't be achieved.. Well thats what updates are for
You're right. There is a huge lack of API examples and documentation. But you can't just dismiss a years worth of documents and examples so far. If anything, it only proves that in time all these building blocks will make it easier to actually whip up a device in a short time.
I also agree there aren't a lot of inspiring devices. But why should the inspiration come from within Max or Live. If almost anything is possible, it might suit you well to look outside the box and just come up with what you want and seek inspiration everywhere.
How would one go about making an "inspiring" device anyway? I can feel another reaktor comment coming up, but reaktor never felt right with me personally. Apart from the Skrewell patch, but that only inspired me to put a scope behind a randomized synth. Didn't even need to build anything, Daniel from Ableton took care of that on extendlive.com .
Anyway, I'm obviously not going to convince you and I'm definitely biased. If more devices and examples is what you want, patience is what you'll need. Maybe this thread might speed things up.
Its just a difference in our thinking I suppose. In reaktor people are used to endlessly browsing synths and sounds. In Max people are used to getting exactly what they want. And if it can't be achieved.. Well thats what updates are for
Re: poor API showcase?
erm.. its not that I have a lack of inspiration..hoffman2k wrote:How would one go about making an "inspiring" device anyway?
ispiring could be anything really.. not something you just build..
but I can name you a few R*****r devices that immediately trigger your brain..
then there's this big gap between great ideas and having the building skills to actually realize them..
you don't have to, I already am.. I really love all the MIDI/modulating stuff..hoffman2k wrote:Anyway, I'm obviously not going to convince you
Re: poor API showcase?
Give the community a go. Since there isn't a single repository of all Max creations, we sometimes have to rely on the brains of others. Its not an ideal situation but there are some big brains out there.Poster wrote:erm.. its not that I have a lack of inspiration..hoffman2k wrote:How would one go about making an "inspiring" device anyway?
ispiring could be anything really.. not something you just build..
but I can name you a few R*****r devices that immediately trigger your brain..
then there's this big gap between great ideas and having the building skills to actually realize them..
I learned Max thru getting pwnd by Machinate. It took me a few months to grasp the fact that externals are building blocks and that there are literally thousands of them. From calculators to physical modeling synths.
And Angstrom is right. In a sense he did dodge a bullet, because before I got my hands on this I too was under the impression "anything" was possible. M4L 1.0 may be off to a little of a rocky start, but there's a feature request section on this forum which I'll rarely need anymore.
Keep in mind, everything that is there is just a combination of what already was. M4L is as much a plugin as Analog is. Apart from a bit of minor stuff, not much got changed to the API either.
Ableton and Cycling have yet to redesign Live and the API to be made to integrate Max.
This means multichannel audio/midi on single tracks. That alone should be good for improvements to the MIDI editor, surround panning effects, unfiltered MIDI, etc..
It sucks that so many people are having trouble with Live 8, because I'm personally ready for 9. I just need some more speakers and one of them 3d tv's.
Oh right, note to self.. Check for 3d render object for Max..
Hehe, guess who's ready for a hologram sequencer in 7.1. Touch screen is soo 2005...
Re: poor API showcase?
im very confused as to what even could be an API default example
so many times i have devices that work, if there are more than 20 scenes and 10 tracks, or the tracks need to be a certain combination like audio midi midi midi audio audio
the API stuff is entirely dependent on what is already in your set
aside from an effect that can start and stop the transport and show the bpm, i cant think of a single API amxd that they could put in to a blank live set without needing addition instructions on how to make it work
so many times i have devices that work, if there are more than 20 scenes and 10 tracks, or the tracks need to be a certain combination like audio midi midi midi audio audio
the API stuff is entirely dependent on what is already in your set
aside from an effect that can start and stop the transport and show the bpm, i cant think of a single API amxd that they could put in to a blank live set without needing addition instructions on how to make it work
Re: poor API showcase?
!!! I simply could not agree more !!!Poster wrote:
I mean if there's one unique thing about MFL its the API related stuff..
also the most difficult material to get into so very important for newcomers to have some prefab devices to play around with..
Example patches are DEARLY needed ... The info boxes of API devices are very hard to understand for many because of the multiple inlets and outlets ...
Re: poor API showcase?
We have abstractions but they are a bit abstract. Some of us are lucky enough to know where to find them. Those of us who find them are usually capable of interpreting where to go from there.zalo wrote: aside from an effect that can start and stop the transport and show the bpm, i cant think of a single API amxd that they could put in to a blank live set without needing addition instructions on how to make it work
This is what I feel is needed:
A tutorial set with 4 audio tracks followed by four midi tracks.
Each track has multiple device racks with parameters that can be modulated by some M4L device. Perhaps an object with a floating interface. Yes- that would be best.
Some tracks will be made using the floating ids while the others would use canonical information of the track # to update the id. Theoretically this will allow users to see how these all work without screwing up the set.
Some tracks should also be set up to receive parameter changes via js examples. I think it's very important users have good side-by-side comparisons to ease their way into this more dynamic method of interacting with the api.
Of course, all of the mixer, send and master elements would have examples as well. This would be great to have. If I knew the JS I could make it but I don't.
This would be soooo helpful. I think I am finally getting to the point where I can type a few correct live paths without screwing up, but copy and paste really seems to be the most reliable method. This template would rock. I might get around to making it. In the meantime I have my clippings.
Re: poor API showcase?
outside of the control surfaces, the LOM has everything you need to know about the API, combined with the abstractions and the API maxpats (which were made to go in bpatchers for the most part) you have a comprehensive example of what the M4L API can do
also, for the most part, working with the API comes down to, an address, a control, and an object/observer/remote
75% of the time my API patches work just like expected with first guesses (i came into max with M4L, with no previous knowledge), the other times the failures teach me the right way and i succeed on attempt 2
maybe its just me, but max seems pretty easy and straight forward, msp and jitter give me a little more trouble, but nothing that an hour of googling and testing dont fix
the API is even simpler than max, there are less objects and everything is mapped out in a single file
most of the time the simplest parts of my patches are the API parts, i guess what im saying is dont be afraid, it seems to me that if you can master reaktor, M4L should be a breeze
also, for the most part, working with the API comes down to, an address, a control, and an object/observer/remote
75% of the time my API patches work just like expected with first guesses (i came into max with M4L, with no previous knowledge), the other times the failures teach me the right way and i succeed on attempt 2
maybe its just me, but max seems pretty easy and straight forward, msp and jitter give me a little more trouble, but nothing that an hour of googling and testing dont fix
the API is even simpler than max, there are less objects and everything is mapped out in a single file
most of the time the simplest parts of my patches are the API parts, i guess what im saying is dont be afraid, it seems to me that if you can master reaktor, M4L should be a breeze
-
josquin2000
- Posts: 36
- Joined: Wed Mar 16, 2005 5:24 pm
- Location: Deep in 'it'.
Re: poor API showcase?
Well, I am not sure you were aware:
They were going to release Max4Live *without* the M4L API at all...
They didn't have enough developers to finish it and finish/test all
the other parts of max4live...so it was not going in at all..(!)
until a single hardworking developer put in *tons* of overtime, just to get a basic set of functionality implemented and tested, but they did not have time to package it all into cool sets of examples...like they *did* with midi and audio basics.
Then they released it all,
and suddenly, they have a *great* need to fix a (relatively) large number of bugs that were introduced...
and all new development, including further efforts on the M4L API were stopped until the program is as bug free as it proudly was before the major v8.1 changes.
You are CLEARLY a Reactor guy, expecting the same "hands-up" on development in the app that you got with the VERY MATURE Reactor. This M4L API is 6-8 years earlier in it's development history than Reactor was when you learned it..with the huge library Reactor's had nearly a decade to build up.
Ain't gonna happen right away,guy... you currently need better computer development chops than many have to get a lot out of M4L API right now... please
a) wait for the app to settle down and then check again: Reactor is years older as application!!!
b) check out the library that grows day by day: http://maxforlive.com
AND/OR
c) become a better programmer...skill of the future! I earn nice living from it, and all I had for training is a PhD in Music composition (professional trumpet player/ art composer until 35y.o, now professionaal Java programmer in insurance industry...) I had no classes, just native intelligence and desire...
so get with it, or wait for those who do to do it for you.
Some people just want it all done for them, others want to be able to do it all themselves....
Please , nothing personal, just reality as I see it...
said.
j2k
aka
cfb
They were going to release Max4Live *without* the M4L API at all...
They didn't have enough developers to finish it and finish/test all
the other parts of max4live...so it was not going in at all..(!)
until a single hardworking developer put in *tons* of overtime, just to get a basic set of functionality implemented and tested, but they did not have time to package it all into cool sets of examples...like they *did* with midi and audio basics.
Then they released it all,
and suddenly, they have a *great* need to fix a (relatively) large number of bugs that were introduced...
and all new development, including further efforts on the M4L API were stopped until the program is as bug free as it proudly was before the major v8.1 changes.
You are CLEARLY a Reactor guy, expecting the same "hands-up" on development in the app that you got with the VERY MATURE Reactor. This M4L API is 6-8 years earlier in it's development history than Reactor was when you learned it..with the huge library Reactor's had nearly a decade to build up.
Ain't gonna happen right away,guy... you currently need better computer development chops than many have to get a lot out of M4L API right now... please
a) wait for the app to settle down and then check again: Reactor is years older as application!!!
b) check out the library that grows day by day: http://maxforlive.com
AND/OR
c) become a better programmer...skill of the future! I earn nice living from it, and all I had for training is a PhD in Music composition (professional trumpet player/ art composer until 35y.o, now professionaal Java programmer in insurance industry...) I had no classes, just native intelligence and desire...
so get with it, or wait for those who do to do it for you.
Some people just want it all done for them, others want to be able to do it all themselves....
Please , nothing personal, just reality as I see it...
said.
j2k
aka
cfb
Re: poor API showcase?
I love this post. Thanks for sharingjosquin2000 wrote:Well, I am not sure you were aware:
They were going to release Max4Live *without* the M4L API at all...
They didn't have enough developers to finish it and finish/test all
the other parts of max4live...so it was not going in at all..(!)
until a single hardworking developer put in *tons* of overtime, just to get a basic set of functionality implemented and tested, but they did not have time to package it all into cool sets of examples...like they *did* with midi and audio basics.
Then they released it all,
and suddenly, they have a *great* need to fix a (relatively) large number of bugs that were introduced...
and all new development, including further efforts on the M4L API were stopped until the program is as bug free as it proudly was before the major v8.1 changes.
You are CLEARLY a Reactor guy, expecting the same "hands-up" on development in the app that you got with the VERY MATURE Reactor. This M4L API is 6-8 years earlier in it's development history than Reactor was when you learned it..with the huge library Reactor's had nearly a decade to build up.
Ain't gonna happen right away,guy... you currently need better computer development chops than many have to get a lot out of M4L API right now... please
a) wait for the app to settle down and then check again: Reactor is years older as application!!!
b) check out the library that grows day by day: http://maxforlive.com
AND/OR
c) become a better programmer...skill of the future! I earn nice living from it, and all I had for training is a PhD in Music composition (professional trumpet player/ art composer until 35y.o, now professionaal Java programmer in insurance industry...) I had no classes, just native intelligence and desire...
so get with it, or wait for those who do to do it for you.
Some people just want it all done for them, others want to be able to do it all themselves....
Please , nothing personal, just reality as I see it...
said.
j2k
aka
cfb
Re: poor API showcase?
ermm, right.. you clearly missed my point..josquin2000 wrote:Well, I am not sure you were aware:
They were going to release Max4Live *without* the M4L API at all...
They didn't have enough developers to finish it and finish/test all
the other parts of max4live...so it was not going in at all..(!)
until a single hardworking developer put in *tons* of overtime, just to get a basic set of functionality implemented and tested, but they did not have time to package it all into cool sets of examples...like they *did* with midi and audio basics.
Then they released it all,
and suddenly, they have a *great* need to fix a (relatively) large number of bugs that were introduced...
and all new development, including further efforts on the M4L API were stopped until the program is as bug free as it proudly was before the major v8.1 changes.
You are CLEARLY a Reactor guy, expecting the same "hands-up" on development in the app that you got with the VERY MATURE Reactor. This M4L API is 6-8 years earlier in it's development history than Reactor was when you learned it..with the huge library Reactor's had nearly a decade to build up.
Ain't gonna happen right away,guy... you currently need better computer development chops than many have to get a lot out of M4L API right now... please
a) wait for the app to settle down and then check again: Reactor is years older as application!!!
b) check out the library that grows day by day: http://maxforlive.com
AND/OR
c) become a better programmer...skill of the future! I earn nice living from it, and all I had for training is a PhD in Music composition (professional trumpet player/ art composer until 35y.o, now professionaal Java programmer in insurance industry...) I had no classes, just native intelligence and desire...
so get with it, or wait for those who do to do it for you.
Some people just want it all done for them, others want to be able to do it all themselves....
Please , nothing personal, just reality as I see it...
said.
j2k
aka
cfb
-
josquin2000
- Posts: 36
- Joined: Wed Mar 16, 2005 5:24 pm
- Location: Deep in 'it'.
Re: poor API showcase?
Hmm... I explained *why* there were no clever tutorials andermm, right.. you clearly missed my point..
example scripts and patches for the MaxForLive API in the original release,
and none from Ableton since.
That is in answer to your original post:
So other than expressing this desire for these examples/tutorials, you had a 'point' I missed?unless I have missed some deep hidden folder why isn't the API stuff represented with the default presets?
I mean if there's one unique thing about MFL its the API related stuff..
also the most difficult material to get into so very important for newcomers to have some prefab devices to play around with..
not even a stock LFO (top 5 request!) or some sort of alternative follow action device, etc..?
is there a relation to the 3 Live main categories? Instrument/MIDI/Audio?
because API stuff would not fit any of those categories.. (shouldn't there be one?)
anyway.. I think MFL is very much undersold by not showcasing its full potential and providing a API jumpstart..
unless I missed that magic folder.. (other than the .maxpat folder)..
I just *know* Ableton would love to have such tutorials and docs,
especially since they are aware it is a difference maker for some people as far as M4L purchase...
They will come when they *can* be made.
Please, nothing personal: it's just a bit much
to expect those tutorial examples *right now*,
given what Ableton has openly confessed
about the state of development in Live and MaxForLive.
I am just trying to make sure people are aware of this,
and hopefully they will adjust their desires in a mature and
understanding way.
I want a more mature API, also...& tutorials, docs would be nice.
But I prefer bug free code, and am waiting quietly, withholding judgment.
Pax, please!
Dr Baker. aka j2k
-
Gregory Taylor
- Posts: 268
- Joined: Tue Sep 01, 2009 3:11 pm
Re: poor API showcase?
I wanted to take a minute to return to this thread from this point because beyond the basic complaints, our poster is pretty much dead on. This provides my excuse to pursue the question of what would or should be a reasonable example, given that:im very confused as to what even could be an API default example
so many times i have devices that work, if there are more than 20 scenes and 10 tracks, or the tracks need to be a certain combination like audio midi midi midi audio audio
the API stuff is entirely dependent on what is already in your set
aside from an effect that can start and stop the transport and show the bpm, i cant think of a single API amxd that they could put in to a blank live set without needing addition instructions on how to make it work
1. The configuration of almost any live set in terms of its mix of kinds of tracks and configurations of effects, etc. is going to vary widely from user to user - and, since using the Live API involves a query interface, that's going to introduce some interesting issues.
2. For some of the more passive users of Max for Live, the expectation would be that an example would be something you'd just drop in and use. for Issues such as tempo, that's not much of a problem. For almost anything else, one would need to modify the patch to use it.
The large number of Live API examples that *are* included with Max for Live appear to represent an attempt to take those things into account. Perhaps the effect of doing that frightens off the programming-averse?
At the moment, anyone interested in exploring the use of the Live API has a number of resources at their disposal - some of which come with Max for Live,
1. Help files (should they contain an example of a more specific use? If so, what?)
2. A documentation vignette on working with the Live API
http://www.cycling74.com/docs/max5/vign ... e_api.html
3. A sizeable list of Max abstractions for use with the Live API
http://www.cycling74.com/docs/max5/vign ... tions.html
4. A collection of Live API examples that are actually sets
http://www.cycling74.com/docs/max5/vign ... mples.html
...to say nothing of the various tutorials and examples posted here and on various websites (such as http://www.maxforlive.com) or Robert Henke's devices (http://www.monolake.de/technology/m4l.html).
So here's my question: I'd be seriously interested to discover what's missing in a more specific way. What of the things listed here don't make sense? What (short of "you should remotely intuit my specific API want and make me a patch") kinds of basic examples are missing or would you like to see?
Any constructive suggestions for what those examples should be? Let's hear 'em!