M4L Browser Zone (Patch in the expandable browser window)

[hoffman2k]

In some cases you have Max patches that don't really process Audio or MIDI.
We create devices that allow the Audio and MIDI pass thru, but when they don't even need an interface or a separate window, it is just a waste of space. And in bigger sets these objects will almost be hidden if you don't keep them on the master or some other "main point".

I would love to see a single patching area in the browser window. This window is expandable and would be perfect to house the things like API controlling stuff, video windows, internet/OSC connection stuff, Mixer view in arrangement, custom file browsers, etc..
Stuff that makes sense to have in your main patch, but don't really warrant individual devices and need more viewing space.

The Live.GUI objects would lose their automation functionality, unless this patching area is considered as a device. But that would probably lead to requests for more patching areas, in which case you can sign me up too as long as it sticks with a single button being added to the browser selector. We could use the bookmarks drop down to switch views.

[halley]

+1

Expanding a little further...
now M4L devices, according to default
I/O objects they contain, are divided in:
- MidiToMidi (Midi fx)
- AudioToAudio (Audio fx)
- MidiToAudio (Instruments)
and they live in a track 'scope'.
Live Object Model documentation confirms that, describing
a parent/child relationship between Tracks and Devices.

There are surely applications of M4L/Max objects that
simply don't live well or don't live at all in a track scope,
and that should be placed, at least from a logical point of view,
in a global (Application) or semi-global (Song) scope, or in some
other smaller 'type' of scope... (Clip, ClipSlot, Scene, View, ???)
Apart from some things that have already been pointed out like:
- control surfaces stuff
- browser related stuff
I'd like to add a couple of examples like:
- multitrack / multichannel stuff
- clip / clipslots related stuff

Some of the M4L patches are ok in the devices visual area.
Some (like some monome stuff) work even better living inside a track,
because simply dropping them in multiple routable/sessionable/fxable/...able tracks
multiplies infinitely the possibilities.
Still... a few things already make you notice that some things simply do not belong
to the track/devices context. Some actual 'global' ways of managing things
(like send/receive) are used more as hacks than bulletproof solutions.
Hopefully in the future we will see improvements related to multichannel audio, ability
to read and use clip paths (i.e. browsing), a closer max_buffer/clip_sample relationship,
and whatever they'll come up with.


For how long will the device area be good enough?
M4L will surely need more logical and visual contexts.

[julienb]

In some cases you have Max patches that don't really process Audio or MIDI.
We create devices that allow the Audio and MIDI pass thru, but when they don't even need an interface or a separate window, it is just a waste of space. And in bigger sets these objects will almost be hidden if you don't keep them on the master or some other "main point".

I would love to see a single patching area in the browser window. This window is expandable and would be perfect to house the things like API controlling stuff, video windows, internet/OSC connection stuff, Mixer view in arrangement, custom file browsers, etc..
Stuff that makes sense to have in your main patch, but don't really warrant individual devices and need more viewing space.

The Live.GUI objects would lose their automation functionality, unless this patching area is considered as a device. But that would probably lead to requests for more patching areas, in which case you can sign me up too as long as it sticks with a single button being added to the browser selector. We could use the bookmarks drop down to switch views.

+1

my patch is an interface between midi from Live to my hardware, from hardware to Live, it includes configuration preset, uses API etc... indeed, it isn't an instrument, a midi effect or even ... a device!

I'd love to see it in another window.
A window that we could expand, move.

[aminoplacid]

Another window would be great. Even an expandable part of a device would be nice like the Sampler or the Spectrum devices how they can expand vertically.

[Tweaking Knobs]

Another window would be great. Even an expandable part of a device would be nice like the Sampler or the Spectrum devices how they can expand vertically.

+1