live.out~ (dreamin')

[stefan-tiedje]

I would love to see a live.out~ object which would allow to route audio to another destination (track). It should be a UI object looking exactly like the menu in the tracks which define the "Audio To".
In addition I'd like to see a live.midiout object which would do the same for Midi data. It should look like the "MIDI To" menu and act like midiout (I patched already workarounds, but they only work for Midi and a dedicated object would make more sense...)
And if you really want to do routing right, add an live.in~ object, non-ui, but a parameter which would create additional audio inputs which in return would show up in the live.out~ menu...
This would at least make it possible to overcome the limits of stereo tracks. But even with a multioutput track it would be very usefull, not only for sidechains (which we can hack together already somehow...)

Stefan

[vanceg]

Yessir big +1 here!

[Palmer Eldritch]

+ 1 also here!

[tasteforreality]

Build it.....

I'm assuming the track input/output settings are changable through the API. Just write an object that lists all the tracks in live and lets you select one from a umenu object. When that track is selected the API gets a path to it and changes the input settings to take audio in from the current channel

[stefan-tiedje]

I'm assuming the track input/output settings are changable through the API. Just write an object that lists all the tracks in live and lets you select one from a umenu object. When that track is selected the API gets a path to it and changes the input settings to take audio in from the current channel

I built something for Midi, for audio it doesn't work. If you are an original Live user you might not have realized that the BIG limitation of Live tracks is, it has only two channels. I am used to many many more...
I don't want to break existing connections to route to other places, I need additional connections (many...)
Even a multichannel track (5.1 or better 8.2) would benefit from being able to route audio to other tracks (sidechaining)...

Stefan

[pyrolator]

Also a double-big +1 from my side

pyro

[elt.net]

+ 1

[pyrolator]

good news:
just read from Anrew Benson of Cycling74:

send~/receive~ between devices didn't make it into the first version of Max for Live, but we are definitely looking at a solution for future updates. We know this is something a lot of people want to do, and it is high on our list of features to implement.
If you don't mind introducing a bunch of latency in the sending, you might be able to hack together a buffer~ based solution.

[jon_moore]

good news:
just read from Anrew Benson of Cycling74:

send~/receive~ between devices didn't make it into the first version of Max for Live, but we are definitely looking at a solution for future updates. We know this is something a lot of people want to do, and it is high on our list of features to implement.
If you don't mind introducing a bunch of latency in the sending, you might be able to hack together a buffer~ based solution.

That is fantastic news indeed. Really love the open approach and responsiveness of the Cycling74 team.

[stefan-tiedje]

In the same thread it was mentioned that plugsend~/plugreceive~ work. After short tests I can confirm they seem to work, though my request is a bit different. But at least we get more options for workarounds...
Now I need to raise enough funds to finally buy a copy of Live...;-)

Stefan

[Gregory Taylor]

While it's possible that plugsend~ and plugreceive~ might work in some cases at the moment, they're not officially supported. I'd expect that you would probably see issues using these object that range from unpredictable latencies all the way to data corruption. After some investigation, I've been advised that it might help somewhat if you disable multicore/multiprocessor support in the CPU Preferences tab in the Live application.

At the present time, there's no easy way to pass audio data in Live predictably and reliably. While there is definitely an interest in working the issues out and providing it in a future version, it will likely not involve the plugsend~ and plugreceive~ objects. If and when some method is supported, those objects will become obsolete and be disabled completely, so you might want to keep that in mind.

[stefan-tiedje]

Thanks for clarifying, I'll try to hack something with a buffer~, I guess that should work, even if I get some latency.
How is the scheduler timing managed within MaxForLive? Is it something like "Scheduler in Audio Interrupt" (linked to the vector size) in Max or is it fixed, slow, unknown...???

Stefan

[emmanuel_2]

Thanks for clarifying, I'll try to hack something with a buffer~, I guess that should work, even if I get some latency.
How is the scheduler timing managed within MaxForLive? Is it something like "Scheduler in Audio Interrupt" (linked to the vector size) in Max or is it fixed, slow, unknown...???

The vector size is hard coded to 64. SIAI is on. Communication between devices is unknown as mentioned by Gregory earlier (because of threading issues), but within the device it should be really tight.

[stefan-tiedje]

Thanks for the info...

but within the device it should be really tight.

Most ideas I have to play around with M4L is between tracks/devices... It shows how much the tool you work with is influencing your creativity. Coming from Max its hard to believe the existing limitations in Live, even compared to other DAWs. If I have a limitation in Max I can patch around it, in M4L its hard...
I was hoping to get a working timeline for Max with the announcement of Max 5. This isn't the case, though I still think a potential is there. Spreaded granular clouds for example are not possible in this scenario (at the moment)...
Creating an OSC bridge between a sequencer and Max was possible before as well. And before we could choose a fully blown DAW to dump our pluggos in...

Live is a fun toy, but its a toy. I haven't bought it yet, (not enough cash for just toys...;-).
I will test EnergyXT inside Max and see if that might be an alternative for now. At least its less than a fifth of the cash...

Stefan

edit: EnergyXT is not an option, the VST only works for windows...

[emmanuel_2]

Thanks for the info...

but within the device it should be really tight.

Most ideas I have to play around with M4L is between tracks/devices... It shows how much the tool you work with is influencing your creativity. Coming from Max its hard to believe the existing limitations in Live, even compared to other DAWs. If I have a limitation in Max I can patch around it, in M4L its hard...
I was hoping to get a working timeline for Max with the announcement of Max 5. This isn't the case, though I still think a potential is there. Spreaded granular clouds for example are not possible in this scenario (at the moment)...
Creating an OSC bridge between a sequencer and Max was possible before as well. And before we could choose a fully blown DAW to dump our pluggos in...

FWIW, send/receive with pluggo suffered from the same symptoms. It's just that in the old days, there were just less thread flying around.