problem with send/receive objects in M4L -by design ??

[3dot...]

really bugs me I that I can't use send/recieve between M4L communicate with say ...a patcher running on the Max Runtime..
I've built a massive patch which is a 'hub' for my dsi evolver..
I load it in Max Runtime so as to communicate sysex i/o directly to the Midi ports...
my idea...
was to make M4L patches for each section of the evolver (osc/filter etc)...
that would communicate with the 'hub' to control the evolver....

well it's done now... and fully working...
but when I try and move the GUI over to M4L...
there's no communication between them...
even if I open the 'hub' patcher from within M4L...

apparantly M4L and Max5 live in seperate worlds...
and send/receive objects communicate only within their host's 'scope'...
and M4L is on a different one...
send/receive which are supposed to work seamlessly between Max patcher windows is crippled...

I guess it's for the same reason one can't access ext. MIDI ports directly from an M4L patch...

but seriously ... it's crippling...

[3dot...]

...and I wouldn't mind working within the M4L realm ..
if only I could get Sysex messages in/out of that place...

[fisk]

i have same problem. modular system built in max, now porting to MfL. the sends work between modules as long as theyre not open in the max editor. this is annoying and prevents live coding. live coding is one of max's best features.

[bencodec]

OSC?

[fisk]

yeah right
introduce a ton of timing errors, great idea

[Gregory Taylor]

I'm not sure what you mean by the term "by design," but it may be useful to consider for a moment that the difference between a device built using Max running inside of Live and the same device open for editing might be two very different situations. In the latter case, one has actually launched a copy of Max and routed all the relevant connections within Live out to this version of Max and then routed them back in. When the edit window is closed, those connections are neither made nor required. This is hardly a detailed explanation, but I hope it sheds at least a little light on the situation.

[fisk]

i think thats pretty obvious from the way its working
is there no way messages can be passed back and forth? i can think of several examples of inter-application communication that suggest it's possible..

[3dot...]

yeah. what I meant 'by design' is 'crippled intentionally'...
if the only way to send receive a bunch of numbers...
from a patch open for editing in M4L and another patch (which was opened from the M4L editor...) is using OSC...
i'd call that a design flaw..

if an M4L device can't access hw midi ports other than through live...
makes kinda sense cuz it's connecting with external/third party drivers and peripherals ...
but we're talking about communication between max objects...withing max...

seems the only solution for me is to move the 'logic' of my patch into live..
and use OSC to communicate it out to my synth...
that's a 'workaround'
...and I thought that M4L was gonna eliminate the need for workarounds...

if the only reason for this behavior is to artificially make a difference between M4L and the full Max5 version...then that sucks....
and that is what I meant in 'by design'..

[pukunui]

We know about the problem with send and receive between devices in Live and those open in the editor. Sorry, it's a complex technical problem and not some evil corporate scheme. It is not going to be addressed for v 1.

The sysex output thing sounds like a Live feature request to me.

-A

[fisk]

hmm not a scheme, but youre definitely not going to address it..
sounds like a plan
is a plan different to a scheme?

and to think i was assuming it was an oversight....

[3dot...]

I don't mind about sysex in live...
live doesn't have the tools to deal with sysex...
I know that
Max does..
I figured if it has objects for sysex then...
I can build stuff with sysex funtionality..

maybe some one should point out the limitations of M4L...

as it is...
I'm 'smuggling' lists of numbers out of Live using OSC... to get them to the MIDI drivers...
and that can't be good..

well...
at least it's recognized as a problem... and will be addressed in some other version(?)...

thanks for clarifying Andrew .

[3dot...]

I would also recommend updating the s/r help files to inform of this limitation..
and giving a full list of limitations of that sort...
(rewire,sync,transport,midiin,live-rack chains etc...)
so as to get the 'big picture' of what we can and cannot do..

[pukunui]

Yeah we will be clarifying this in the docs. Sorry for the current inconvenience.

-A

[Poster]

wow.. no sysex.. I knew it, but didn't realize till now that Live doesn't eat it..

that's really too bad since I was just about to rebuild this patch
http://stretta.com/~matthew/resources/e ... index.html
to have control over my Evolver from Live..

[hoffman2k]

If you browse the control surfaces API, you'll see a function called "handle_sysex".
The messages being sent to and from novation/mackie displays is sysex. Messages from devices like the APc and the Launchpad also contain sysex.
Basically, Live's remote control surfaces section already handles sysex. Another point to prove that is the sysex based API hack which started a lot of this.

Live does support sysex, but not on the track input and output which is where we want it.
Which makes me wonder, could we actually pipe in/out pure sysex once we get control over the remote control surfaces stuff in M4L?