maxforlive devices format/type conversion

[tiago_vla]

I've stated that if you create a device of midi type effect, or audio effect, or instruments effect (whatever), you cannot convert it to another type.. let me explain this better, if you create an audio effect, and then you decide to give it both plugmidiin an plugaudioin, you cannot convert it to another type of device, or even using it in two categories.. I think it is a limitation if, for an instance, you want to create a device that opens both, in midi, and audio tracks.. so take a look at it, and try to figure out ways of solving it..

ANOTHER THING I ACTUALLY THINK YOU SHOULD LOOK AT, IS FOR AN INSTANCE, TO CREATE THE POSSILITY OF A TRACK TO RECOGNIZE THE DEVICE TYPE, DIRECTLY AND THEN, IF REASONABLE, TO CONVERT THE TRACK TO THE DESIRED TYPE..

YOU SHOULD CREATE THE POSSIBILITY IN THE PATCHER INSPECTOR FOR THE USERS, TO DETERMINE IF THEY WANT A HIBRYD DEVICE, OR WHICH TYPE DEVICE

[Gregory Taylor]

Or you could do what I do without even giving it a thought: create
a new blank device of whatever type you want, then copy and paste
the patch bits between windows. Does that seem unneccessarily difficult?

[tiago_vla]

no, but that would be a must value, for optimizing maxforlive for people who are not fluent in maxmsp (which is not my case, once I study max at least at two years from now, but you have to look at the accessibility of the programme, for begginers).. besides that I've typed things from the beggining in max for live since yesterday.. and imported some stuff to the environment, but it is always, a most value

Or you could do what I do without even giving it a thought: create
a new blank device of whatever type you want, then copy and paste
the patch bits between windows. Does that seem unneccessarily difficult?

[tiago_vla]

HAVING HYBRID DEVICES IS ALWAYS IS USEFUL

[Veqtor]

A big problem is not being able to send midi notes to audio effects at all IMO...
Sure, devices need to be classified as audio OR midi-effects, but I think it should be possible to route midi to audio effects and vice-versa, why?
Well, for one, it would allow a vocoder effect to receive notes that drive a synthesizer.

Also, it seems that plugin~ doesn't handle multi-channel audio yet, that is,if say 4 channels are defined in plugin~ or plugout~ it is not available for routing within Live, so we cannot create side-chain compression or multi-output devices this way.

[Surreal]

The patches live in tracks. the tracks can only pass the data that they understand.

midi tracks have one midi in and a variable number of midi/audio outs.

audio tracks have an audio in and an audio out.



use a send and recieve object pair and you have a workaround

[Gregory Taylor]

I would not automatically assume that sending audio between devices on different devices on two different channels would be a reliable thing to do in terms of
things like latency without some checking (and by that I mean using send~/receive~ objects).

[vanceg]

I would not automatically assume that sending audio between devices on different devices on two different channels would be a reliable thing to do in terms of
things like latency without some checking (and by that I mean using send~/receive~ objects).

???? I had heard (quite some time ago) that sending audio from a M4L device on Track 1 to a M4L device on Track 2 using Send~ and Receive~ would not be possible....so I havent' tried it. Perhaps I should! This might help me get around the "stereo in/stereo out" limitation of M4L devices!

Vance

[Jean-Francois Charles]

It's surely recommended to use send/receive rather than send~/receive~ (the first thing that comes to mind about send~/receive~ is latency: I'm not sure how it would be handled.
The "audio XOR midi" input for a device is a Live limitation, so we have to use something like send/receive.
Sure, Midi + Audio are most useful when combined. And it's getting fashionable (see NI's new The Finger).
J-F

[Veqtor]

Well, I for one have been using reaktor like that, sending midi-notes to it when it is used as a audio-effect... So I wouldn't say it is one of live's limitations really...

[Machinate]

it *is* kind of silly, but it's also EXTREMELY easy to have:

max midi plugin: midi input, prepend track info or whatnot, then [send myvocoderapp]

Audio effect: [receive myvocoderapp]



Now, the REAL problem, the way I see it, is you can't easily feed, for instance, two stereo tracks into a convolution patch or a vocoder... or, get 8 audio outputs from one patch. Now, I've done workarounds for that, but trust me, they're UGLY.

I really hope this is the focus of future development, since it is a bit sad to see normal VSTs with better connectivity than MaxForLive, to be honest.

[stefan-tiedje]

I never understood why there is a distinction at all. Literally all my audio effects have some sort of Midi control, most of them require note input. For example, I'd always connect the frequency of a resonator to a pitch control, which intuitively would be a keyboard. Any device could have Midi in and audio in, as well as Midi out and audio out.
I am not too much into sequencers, but all have different types of tracks. But I naively believe only for historical, not for practical reasons.
This issue of course is addressed to Live and not to Max. Maybe a future Live version will have a simple universal track type, if there is no audio going through, then it would simply not load any audio code into the track. If there is a midiin object, it would create a midiport, if there is a plugin~ object it would have an audio input. If it would have 6 audio outputs the track would for a 5.1, if it would have 8, the track would be for spacialized live music, if it has in addition a midiout, I should be able to send it to a synth in another track...

I know I am just dreamin'... (and gimme some good reasons to understand why it is like it is...)

Stefan

[fisk]

one of the reasons i adopted max in the first place was cos it allowed me to make midi/audio hybrids. the distinction is completely unnecessary, surely any amxd can be defined by what objects it contains.. why do we have to keep banging on with the age old 'midi/audio are different disciplines' thing?
we all know theyre not...