The lack of a good, centralized M4L Community?

[steff3]

>>
Still not getting it. What exactly is your problem here? Do you want live.dial to have dynamic min and max according to the chosen parameter? Its not possible, but then again you can't change the range of an actual control on an Ableton device.
If you want the actual value to displayed on a 0 to 1 ranged knob, use the scale object to give you the right value. And whichever object fits the bill to display the value under the dial.
>>
Well, with the live.dial you have two ranges - the one you set in the inspector ( which comes out of the left outlet), and a range from 0.-1. on the right outlet. The left is also displayed.
In Live you have controls that have e.g. a visible range of -100 to +100 (the next minor thing is, that in Live devices some values are displayed as floats for x < 10 and as ints for x > 10 or put another way, always display two digits when smaller than 100) and have an automation range from -1. to +1. (which you get when you get the value over the API). If I am not mistaken this cannot be achieved with the live.dial (without workarounds). I can display from -100 to + 100 but then only have a range from 0. to +1. on the rigth output. Of course I can make divisions or use expressions - but the thing is called a live.dial but it does not have the functionality to really act as a dial control that I find in Live devices. It does not behave like that and I need workarounds. No show stoppers ... it just seems to me that it is a lack of attention that went into Live.dial. (Ok, it looks like a Live dial and maybe this is all it is supposed to do)
The other thing is that it would be nice to know the scale (curve or exponent) that is used for the params on the live device. As you cannot control the param when it is linked (ok, I have a button to unlink and adjust the param on the device and then relink again and read out the new value).

>>
The device I'm working with disconnects and reconnects the API device controls every time the transport stops, in order to create an undo event. So I'm not sure why you're having trouble with this. I am not a JS wizard though, all my API stuff is done with objects.
>>
I have no problem to connect or link to it, but to automatically relink/reconnect when I reload a Live set. When Live is running - no problems, works great. Also others reported that they also have those problems to automatically relink API connections automatically when opening a live set with such M4L devices (and using Max modules not JS).

In other words - I have a M4L device that links to another Live device (a Corpus) and controls params of that. When I set it up it scans the Live sets for Corpus devices and lists them and lets you select which one you want. I then saves the track number und device number. When the set is reloaded the M4L device receives those two numbers from pattrstorage and has to relink to the device. The problem, I do not know when the LiveAPI is available and accessible - just know it seems not accessible when pattrstorage transfers the store values and it seems not available at the time M4L loadbangs.
Of course I could query when the LiveAPI is available, but I think Live should tell me, when it makes the API available.

As I said, of course there are workarounds. But what would we say I I first had to count to 130, then press a key-combination while tracking the Sampler onto a track? Of course it would work, but we would pretty certainly tell Ableton that we thing there is a better solution and that they should think about implementing it.
Also, if Live would remember which devices where loaded, but you had to reload the presets because at the time the device was loaded live could not load preset data or whatever. Or you would have to reassign side-chain connections because the other device was not yet loaded when Live tried to set up the side-chain connection.
And in some parts M4L exactly feels this way to me.

As I said, of course those things take time ... of course it is a question of what to expect. There are lots of little quirks like that and I think we have to live with quite some of them - they are perhaps just manifestations of the different approaches behind Max and Live.

Just my 2€cents

thanks for your interest.

best

[Machinate]

more importantly; what does that have to do with a centralized M4L community?

[jon_moore]

more importantly; what does that have to do with a centralized M4L community?

Agreed, lets get this thread back on point!

The discussion so far has been intelligent and considered with lots of legitimate views.

[gavspav]

My take on it is that it would help the establishment of a MaxforLive community to have a single forum at this stage. There isn't that much information yet and its easier to have it all in one place. Its just less clicking!

Such a forum could be reached from the Cycling 74 and Ableton forums and it could easily have subsections for more Max related and Live related questions.

However thats just my opinion. There are at least 3 forums already and it seems unlikely that any of them are going to close.

Failing that, maybe one of the third party sites could make a forum which collates the posts from all the other forums as well as the you tube and vimeo examples and tutorials, wikis, google waves, tweets, facebook groups, blogs etc.

Or maybe someone could make a M4L device which provides access to all of this!

[JuanSOLO]

I was thinking about posting quotes from Ableton and Cycling74 which point to Ableton as the captian of the M4L ship. However the evidence is simply that there is no "official" M4L forum on the Ableton site. Is it really still in it's Beta stage? Come on really???

Thats rediculous!

Any sort of rebuttle to that is equally strange.

Issues about wether or not M4L should mirror Reaktor, differences between Max users and M4L user intentions, people who patch or people who dont, Multiple forums, 3rd party sites, is a relative perception.

Fact: Ableton has no M4L forum.

Weird. Seriously that's F'd up guys.

[stringtapper]

Well, apart a few bits (ads and self-promotion which are absolutely the right of the person or persons who set up the websites in the first place), it would appear that they're each doing things just a bit differently, for whatever reasons. Again - I don't think it's a bad thing. But I'm old enough to remember shopping in the former East bloc, and living in American state where there was only one state-owned liquor store.

I'm also suspicious of the false efficiency of single sources and single solutions. But that's probably just me.

Greg I agree with most of the things you've said far. My point was that I thought the fact that even a Cycling '74 employee didn't know that there were already private M4L sites out there (for months) sort of highlighted the need for a central location where at least information can be disseminated.

I think that the bottom line is this:

Max for Live is an Ableton product.

I don't think much more than that needs to be said regarding why they need a dedicated forum.

[Gregory Taylor]

[quote="stringtapper"]I think that the bottom line is this:

Max for Live is an Ableton product.

I see it differently, I guess. While Ableton sells it [no doubt the result of some earlier negotiations to which we were not privy] and some of their decisions about how the program works at a very low level certainly affect what is possible in M4L [i.e., if the Live API doesn't expose something, there's no way that you can use Max to do some kind of end run around what the Live API didn't expose], it's a version of Max that runs inside of the Live application. I think that the best way to go is to ask questions about the Max programming environment where Max programmers hang out, and anything that's left over would be asked here (there's probably at least an order of magnitude more Max programmers over on the Max forum than you'll ever see posting here, so that seems to maximize the chance that you'll find a better answer or set of answers there - provided that you're willing to work with the differences in Max and Live as user cultures). My personal guess about why we're still hanging out in the beta discussion list is pretty modest - when M4L went live, there was a whole bunch of discussion about using the program already in the beta discussion list and - for someone in the giant Live anthill - it was simply easier to leverage those previous discussions by not moving and renaming the entire pre-existent hierarchy (something I can imagine being a large and odious task, given some of the site management tools out there).

[mastahlee]

Great points, guys. I'm glad this conversation has remained so civil and constructive.

It seems that most people tend to agree with me that the perception is this is an Ableton product, meaning that they should ultimately take ownership of the community and be the gatekeeper/first-stop for everything Max For Live related. This notion makes the fact that people are confused as to whether the Cycling74 forum is the official forum, with this Beta Discussion forum now done serving its purpose and should be abandoned, even more aggravating. If this is an Ableton product, why does it seem like Cycling74 is more on top of providing support to the community?

Can we get any clarification from someone officially from Ableton about this confusion?

All these things bother me because it is apparent to me that a healthy community is what will make or break Max For Live. Unlike, say, the Launchpad or APC40, where there is an easily definable and clear standard use case, the community isn't as essential. Sure, a community has cropped up to extend their respective capabilities but their most popular use (and the reason many buy these devices) is already fully baked and designed. Max For Live is just a toolbox, a set of potentials. Nobody is buying it just for the buffer shuffler or the step sequencer. At this point it is just raw POTENTIAL. I don't care if you're the kind of person that never uses anyone else's code, everyone benefits from a robust and active community with this sort of software because it is the community that ultimately demonstrate examples of really innovative implementations. The "Damn, I never would have thought to do THAT!" examples. I hope this lack of attention from Ableton we're seeing right now is just a combination of release exhaustion and things slowing down for the holidays.

Honestly, if an Ableton rep came into this thread just to say "I am too wasted on eggnog to deal with this right now. We'll address your issues after the new year." I would be content. Just give us something!

[mastahlee]

I think that the bottom line is this:

Max for Live is an Ableton product.

I see it differently, I guess. While Ableton sells it [no doubt the result of some earlier negotiations to which we were not privy] and some of their decisions about how the program works at a very low level certainly affect what is possible in M4L [i.e., if the Live API doesn't expose something, there's no way that you can use Max to do some kind of end run around what the Live API didn't expose], it's a version of Max that runs inside of the Live application.

This is what causes a lot of the confusion, because as I see it Max For Live is essentially two products:

1) Max/MSP/Jitter as a live device.
2) A programming language for interacting with the Live API.

As far as I'm concerned, product 1 is much less interesting than product 2. You could already pretty much DO product 1 before M4L by just making pluggo plugins of your Max patches. M4L just makes it a little easier. That stuff is old news, and if you want to make a granular synth from scratch there is definitely a very active Max community of which you can appeal to.

Product 2 is what, I think, at least 75% of what most people were excited for with Max For Live. An official API with a well-understood language to manipulate it. It appears to me that 90% of all the posts (and 100% of all the duplicate posts) in both Beta Discussion and the Max For Live Cycling74 forum are about questions that focus on only 3 objects: live.object, live.observer, and live.path. Nobody in the regular Max forums will be able to help you with questions regarding these three objects. This is where the confusion of where the support comes from lies.

Are these three objects supported by Cycling74, or Ableton? They only exist in Max For Live, which is an Ableton product. Why doesn't there seem to be real forum to discuss them? What about the rest of the Live Object Model? Is it appropriate to ask questions about the LOM in Cycling74's forum when Live isn't even their product?

[Gregory Taylor]

What would be wrong with claiming that there are two "official" forums, one of which is a place where you pose questions related to programming in the Max environment, and the other being a place to ask about anything related to how stuff specifically works in the Live environment? I'm somewhat mystified as to why that should be so difficult. Personally, I enjoy the Max forums a bit more - less serial hollering and demands for implementing one's personal habits as single solutions. But that is, no doubt, why I gravitated to a programming environment like Max in the first place.

One question you might want to ask yourself would be why you don't see quite so many seasoned Max users posting about stuff here beyond asking about how their current knowledge base maps to what they use. That was a good deal more prevalent in the beta phase, and now those users are either gone or they're just doing the work [probably a mix of both]. I expect it's a cultural difference. In any crosscultural situation, I remain wary of anyone who wants to force assimilation on me.

[Gregory Taylor]

I remain generally unwilling to divide the product and claim that my personal preferences are the obviously important bits, but - assuming that you really are all fired up about messing with the Live API - then things are easy. That ball is in Ableton's court. They spec'd and designed and developed and maintain it. M4L merely provides some Max objects that allow you to interact with the Live API, and those objects support anything that the Live API has exposed. When things change [as with the recent addition on Ableton's part of the playing_position stuff], it'll be accessible through the Max for Live externals. In any situation where there's some kind of specific order of operations internal to Max itself (for example, knowing that the order of initialization for a patch is 1. Live parameter enables 2. pattr 3. loadbang methods in objects 4. loadbang object-initiated stuff), I've tried to determine the state of affairs and offer answers here.

I'd ask all those questions here. Period. Nobody who's a regular Max programmer will know about them or care about them or use them unless they decide to become Max for Live customers - so asking questions on the Max Forum wouldn't be a good use of your time. See how easy that was?

<I'm editing this because a colleague just read this and suggested that I might suggest a situation in which asking a question in the Max forum WOULD make sense>

Suppose you're interested in doing something with granular synthesis. That's definitely a Max forum question, although I would suggest that one cultural difference is that you're likely to get a list of pointers to various approaches or links to previous forum articles or instructions to look in the Max example patches folder to see something you've already got. The expectation in the Max community - since it is a bunch of programmers - is that you'll take that stuff and learn how to modify or port it yourself. At that point, you might certainly consider sharing the device you ported with others here, etc.

[jon_moore]

Suppose you're interested in doing something with granular synthesis. That's definitely a Max forum question, although I would suggest that one cultural difference is that you're likely to get a list of pointers to various approaches or links to previous forum articles or instructions to look in the Max example patches folder to see something you've already got. The expectation in the Max community - since it is a bunch of programmers - is that you'll take that stuff and learn how to modify or port it yourself. At that point, you might certainly consider sharing the device you ported with others here, etc.

I think this is an important cultural distinction between many M4L users and traditional Max programmers. Even though M4L is a very different product to Reaktor or AAS's Tassman, I've read many requests here on the Ableton forums from individuals looking for help at a far more macro level (they expect a similar ability to 'plug & play' devices together from existing modules much as you can with Reaktor or Tassman). These individuals are likely to get completely lost in the advice offered to them on the C74 forums (experienced Max programmers assume a certain aptitude to begin with when offering advice). They're not looking to create devices that integrate with the Live API but neither are they looking to programme a Max synth/effect from scratch. The need advice on how to combine the supplied M4L building block elements into bespoke devices.

[Gregory Taylor]

That's a good point, but what you're describing as a simple request may not be simple at all. Msking those changes will, sooner or later, get you down to something like this: it's a programming environment, and it will favor people who can read (at least until some enterprising soul videotapes himself doing every single Max tutorial or some similarly useless nonsense) and familiarize themselves with its use. Otherwise, the colloquial expression for what one has otherwise is called "cargo cult patching" (the practice of randomly disconnecting and reconnecting things in a patch without the slightest notion of what they do) in some parts of the Max world.

For those folks, there are several happy options:

1. All Max help files (at least attempt) to demonstrate the basic and common uses of an object. They're all Max patches that you can unlock and paste into the patch you're working on).

2. The tutorials included with Max for Live about programmming in Max were specifically chosen to NOT precisely track the Max or MSP or Jitter tutorials - rather, they focus on issues basic to creating devices and they are lavishly commented.

3. Anyone who wants a good general introduction to how Max itself works - messages, data types, and how data moves about in a Max patch would benefit considerably from the Max tutorials themselves. Apart from a very few exceptions related to low-level implementation issues with the Max for Live implementation (send! and receive~ objects aren't implemented in Max for Live, Live UI devices are not described in the Max tutorials), they contain almost everything you need to know.

While it's certainly possible that Live culture might be more focused on having one's solutions provided to them by a single source or there always being a single answer for everything, I think that there is already a wealth of possible solutions available - almost all of which are sitting on your machine right this minute waiting for you to type something into a search engine. That multiplicity of sources - while not exhaustive - seems quite a reasonable place to start. Working with something like Max is more like a natural language in that regard - you don't walk off the plane in Lisbon and expect to be writing villanelles like de Pessoa. You start by learning the language. If you've got any questions with the language, then ask questions of its native speakers. Questions about Max for Live as a dialect? Ask it here (or bellow it, as sometimes seems to be the case ).

[jon_moore]

While it's certainly possible that Live culture might be more focused on having one's solutions provided to them by a single source or there always being a single answer for everything, I think that there is already a wealth of possible solutions available - almost all of which are sitting on your machine right this minute waiting for you to type something into a search engine. That multiplicity of sources - while not exhaustive - seems quite a reasonable place to start. Working with something like Max is more like a natural language in that regard - you don't walk off the plane in Lisbon and expect to be writing villanelles like de Pessoa. You start by learning the language. If you've got any questions with the language, then ask questions of its native speakers. Questions about Max for Live as a dialect? Ask it here (or bellow it, as sometimes seems to be the case ).

I'll be honest here, I find your last response incredibly condescending to the Ableton Live community. While I would agree there are large swathes of users on these boards whose behaviour and expectations can be described as juvenile at best. There are also a number of highly experienced music technologists that love the non linear approach of Ableton Live and are attracted to the expansive possibilities brought about by M4L.

I personally went through most of the steps you describe (completed all of the included M4L, Max, MSP & Jitter tutorials) when I joined the private beta a number of months back and have publicly congratulated both the Ableton & C74 teams for the quality of the included tutorials and more importantly the level of detailed annotation within the building block devices. The original discussion however was about the need for a centralised M4L community and I wanted to voice my belief that this user community also needs to service the large number of M4L users who don't wish to learn the Max programming environment at a deep level. Of course I agree that the greater your command of 'the language' the greater the return, but a large number of M4L customers have never encountered a visual programming environment before and standard arrogance of RTFM helps nobody.

[Gregory Taylor]

Some things just don't come across well, I guess.

No condescension was intended. Rather, there is often quite a difference between something that functions as an end-user product where lots of low-level decisions were made on your behalf which you're shielded from in the name of making things "easy" vs. something more along the great continuum toward actually coding in a high-level language where you actually have to make all those decisions for yourself. Max is further in the direction of the programming language, and there's really no other way to say that. I would expect as a matter of course that Live users are more accustomed to the former case, and it would appear from my experience and reading thus far that this is the case. Like any opinion, mine is provisional and subject to change.

But I would also say that *any* programming language does, to some extent, privilege the written word and reward literacy and enterprise. However, I would be more comfortable having the F in RTFM refer to the word "Free," as is the case with what I've described. Do you know the (justly) famous online hacker bible "How To Ask Questions the Smart Way?" (http://catb.org/~esr/faqs/smart-questions.html). I have learned much of its content the hard way, but commend it nonetheless.

I have no problem with recommending that someone take advantage of the numerous resources available to them. It's how I learned what I know, and if I'm making any assumptions here, it's that you're at least as good a reader as I am. If my listing was too high-level for your tastes, it was because I'm talking about a general case rather than suggesting that you look at Max tutorial X for information about using the Y object or checking the subpatcher called "foo" in a given M4L tutorial. If you want better answers to a given problem, asking more specific questions almost always obtains.

Given what you're describing, it would appear that you have a perfectly good place to ask questions about Max for Live - right here. My guess is that someone at Ableton is working to put the repository they've mentioned earlier, and in the interim you have at least two people who have some vested interest in putting some mechanism in place to distribute things that you make for the benefit of others until that happens. Not bad for a product that's not been out for a month yet, is it? Since you seem to have a better grasp of what users here want, why not make and put up some devices that you believe would meet some of their needs?

If you've looked at the tutorials and all that, perhaps you might help me by telling us what someone who's never seen a graphic programming language before would need to know that (for example) the Max Tutorial 0 and the basic tutorials wouldn't tell them. That seems like as good a place to start as any....