Is it possible to peek~ waveforms into the Live Sampler?

[flowdesigner]

Hi,


Is it possible to peek~ waveforms directly into the Live Sampler?

[henke]

No, currently not. And it will not happen any time soon. The API which can be accessed via M4L's API objects has originally been written with the sole purpose of connecting commercial HW controllers with Live. I am quite confident that we will extend the API in the future, because now with M4L it really makes sense to do so. But our primary goal for now is getting the existing structure as smooth as possible. Your wish is noted, though.

Cheers, Robert

[disco judas]

sounds good

[Homebelly]

No, currently not. And it will not happen any time soon. The API which can be accessed via M4L's API objects has originally been written with the sole purpose of connecting commercial HW controllers with Live. I am quite confident that we will extend the API in the future, because now with M4L it really makes sense to do so. But our primary goal for now is getting the existing structure as smooth as possible. Your wish is noted, though.

Cheers, Robert

As a complete novice to Max, and so not really all that conversant with the language, is this then an indication that some aspects of live devices might become available as "Abstractions" - if i understand what an abstraction is - or some other kind of object that can be used as a building block in Max at some stage further down the line?

[stringtapper]

No, currently not. And it will not happen any time soon. The API which can be accessed via M4L's API objects has originally been written with the sole purpose of connecting commercial HW controllers with Live. I am quite confident that we will extend the API in the future, because now with M4L it really makes sense to do so. But our primary goal for now is getting the existing structure as smooth as possible. Your wish is noted, though.

Cheers, Robert

As a complete novice to Max, and so not really all that conversant with the language, is this then an indication that some aspects of live devices might become available as "Abstractions" - if i understand what an abstraction is - or some other kind of object that can be used as a building block in Max at some stage further down the line?

I don't see anything in Henke's response that would indicate that and they've never indicated that Live devices themselves would be opened up or anything. The Live devices weren't coded in Max so even if they did do something like that the abstractions or building blocks you would get would still be prototypes created in Max and not actual pieces of the Live devices. There are already plenty of building blocks provided with M4L that help do all kinds of cool things.

[Homebelly]

No, currently not. And it will not happen any time soon. The API which can be accessed via M4L's API objects has originally been written with the sole purpose of connecting commercial HW controllers with Live. I am quite confident that we will extend the API in the future, because now with M4L it really makes sense to do so. But our primary goal for now is getting the existing structure as smooth as possible. Your wish is noted, though.

Cheers, Robert

As a complete novice to Max, and so not really all that conversant with the language, is this then an indication that some aspects of live devices might become available as "Abstractions" - if i understand what an abstraction is - or some other kind of object that can be used as a building block in Max at some stage further down the line?

I don't see anything in Henke's response that would indicate that and they've never indicated that Live devices themselves would be opened up or anything. The Live devices weren't coded in Max so even if they did do something like that the abstractions or building blocks you would get would still be prototypes created in Max and not actual pieces of the Live devices. There are already plenty of building blocks provided with M4L that help do all kinds of cool things.

I understand that lives devices aren't coded in Max. And I don't ever envisage that they ever will appear with an edit button that allows them to be opened up in max in all of their naked glory.
However, if both the Abes and Cycling are working together, surely its not so far fetched, however, to wonder if maybe the basic components might become available in some form. For example the Ocs section, the filter section, the envelope section and so on. Kind of like the macros in Reaktor.
Or how about being able to attach a plugin~ to the front of sampler/simpler so they can be used as on the fly old school sampler?
Simpler/sampler them selves would be the "External" or "Abstraction" available through some aspect of the API.

I really have only limited understanding of the language and concepts i'm riffing on here.
At this point i feel as though i am looking out onto a huge blank and undefined vista where any thing is possible.
But inside of this world i am imagining being able to build my own instruments or FX based on the parts of the live devices i already know.
Kind of like a super rack that is able to communicate with its self behind the scenes if you like.

[stringtapper]

However, if both the Abes and Cycling are working together, surely its not so far fetched, however, to wonder if maybe the basic components might become available in some form. For example the Ocs section, the filter section, the envelope section and so on. Kind of like the macros in Reaktor.

The basic components are available, you just haven't built them yet.

But seriously, some are available in the Tools and Building Blocks folders.

These types of things aren't all that hard to code in Max, you just have to do it. What you're talking about will probably become someone's project soon; a project to create a set abstractions and clippings that have specific audio and midi effect functions. Maybe you'll be the one to do it.

Or how about being able to attach a plugin~ to the front of sampler/simpler so they can be used as on the fly old school sampler?

Wasn't that the very question posed by the OP, or at least something very similar? I think Henke said no, but maybe some day.

Simpler/sampler them selves would be the "External" or "Abstraction" available through some aspect of the API.

Not the devices themselves, as we've agreed they are not coded in Max. But you could recreate them as abstractions. A coder would have to make an external as those are coded in C.

At this point i feel as though i am looking out onto a huge blank and undefined vista where any thing is possible.

You are. But…

But inside of this world i am imagining being able to build my own instruments or FX based on the parts of the live devices i already know.
Kind of like a super rack that is able to communicate with its self behind the scenes if you like.

…having an idea of what you want to accomplish is the best way to proceed with learning Max. In fact without some idea you only find yourself staring into that void. Go through the tutorials, master the basics, then take one of your ideas that you've listed and get to work on it.

[halley]

I won't argue about Live devices. Not only I know that clearly are not programmed inside Max,
also I totally agree with stringtapper and others about the fact that Max/M4L environment
is really about programming 'your own devices' and having them appear like Live devices,
alongside ableton-programmed ones.



I will argue a bit about this:

The API which can be accessed via M4L's API objects has originally been written with the sole purpose of connecting commercial HW controllers with Live.

I am sorry if this sounds polemic, but
if really M4L API objects has been originally written with 'that' sole purpose...
how is it that there are still some sysex and multi-channel midi input/output 'issues'?
and
how is it that there's still no documentation for control_surfaces objects?
(Not even for ableton's officially supported commercial hardware like APC40 and Launchpad?)

Cheers

[henke]

I won't argue about Live devices. Not only I know that clearly are not programmed inside Max,
also I totally agree with stringtapper and others about the fact that Max/M4L environment
is really about programming 'your own devices' and having them appear like Live devices,
alongside ableton-programmed ones.



I will argue a bit about this:

The API which can be accessed via M4L's API objects has originally been written with the sole purpose of connecting commercial HW controllers with Live.

I am sorry if this sounds polemic, but
if really M4L API objects has been originally written with 'that' sole purpose...
how is it that there are still some sysex and multi-channel midi input/output 'issues'?
and
how is it that there's still no documentation for control_surfaces objects?
(Not even for ableton's officially supported commercial hardware like APC40 and Launchpad?)

Cheers

Misunderstanding. Not the M4L API has been written for that purpose, the original Python API inside Live has been. For M4L we unified the calls to work from M4L and Python. The reason that there is still a lack of documentation is simple: not enough man power to do all this. As I stated earlier, we initially discussed not even having the API as part of the initial release. Mainly thanks to one of our main developers, who put a tremendous personal effort into this project it was possible to add it at all at this state. We are absolutely aware that the API needs more documentation, that functionality is missing and so on. It will come...

Robert

[halley]

In this electronic and machine oriented world, sometimes it's easy to forget about man power.
thanks for answering the bitter questions.
And thanks to 'the' passionate developer.

I'm glad that even with something missing the API made it for the initial release,
also because it's the only 'officially' exposed and supported version of Live API.
Python LiveAPI hacks were acknowledged but never really supported.
(with support I mean at least some tools for compiling and debugging,
documentation of the API, eventually sample code and/or libraries...)


Given that M4L exposes the API to the public, I guess that the process
of unifying/mapping calls to work from M4L and Python is somehow needed.

Will the API ever be accessible to Live customers that haven't bought M4L?
Or is somehow M4L 'the price to pay' for Live API official support?

These questions are just out of curiosity.
I am an happy Max, Live, M4L owner and have always managed to do things
one way or another, but I also believe some friends of mine have some
pretty strong arguments when talking about some of Live's MIDI shortcomings.

[flowdesigner]

Thank you, Robert. Its always so cool to see when you have replied to the topics

But Peek~ing and rendering only the singlecycle waveform in maxforlive, and dragging it into Sampler, can be done in not so very many steps, no?

[monohusche]

peek~ gives you low level access to MSP buffers which are not related to the internal Live buffers. Of course, you could save the buffer from within the patch to a file which then could be loaded into sampler, but so far, the Live API doesn't give you access to the file system or the browser.

what do you want to accomplish ?

nick

[flowdesigner]

Thank you,


Nothing special i try to achieve, just that i think Sampler is a very cool synth when loaded with single cycles, and I wanted to make the cycles with peek~ and get them into Sampler with as few mouseclicks as possible.

Cheers

[andrewbenson]

Doing wavetable synthesis in MSP isn't that difficult, once you get a few tutorials under your belt. That might be a more versatile way to approach this.

[Homebelly]

Doing wavetable synthesis in MSP isn't that difficult, once you get a few tutorials under your belt. That might be a more versatile way to approach this.

I'm interested in this idea.
I have done the FM synth tutorial that is part of the live lessons for M4L.
I have a few questions about using the buffer~ to store wave forms that i might ask about later if i don't stumble across the answers my self.
Mean time..
What other tutorials should i be looking at?