you wanted to know what program i think manages windows well? i think the windows explorer does a nice job. im not talking about IE the internet browser, but the disk browser that comes with windows. you could easily adapt the idea for mulab, each mux being a folder with contents that either do something or contain things that do something. its like a folder tree. imagine being able to jump to almost any window in the tree instantly because you can see them all in miniature in the left pane (and collapse the tree as you wish to show less). this would also make the module hierarchy implicit. not to mention many people are already using the paradigm and would warm up to it quickly as a result imho.
Last edited by > DiGiT < on Sun Oct 21, 2012 9:59 am; edited 1 time in total

First of all, thanks for going on with this Digit, and not being disappointed by the fact i did not yet implement a quick (and then maybe unsufficient) solution for this. Also because of the priorities i'm working on, you know that by now.

I think that's a very interesting idea you bring on!
Eventhough it does not yet answer to the whole windowing/docking challenge because sequence editors etc are not included in the MUX tree.

But anyway, it's a very interesting idea, not only for windowing.
We do have this tree list already when choosing a track target or when mapping meta parameters, now lets see how this can bring us even more comfort during jamming and music production. Mmm sounds also related to the browser topic...
Interesting.

Ok, i've been thinking a bit about this, window-topic-wise, and i wonder how you see this concrete? Do you want a MUX function like "Show sub-editor" then the tree list appears for that MUX? If yes, then is such function actually answering the original question for having a even quicker way to access already opened windows (besides the existing Ctrl+Tab way)? Please elaborate.

hmm i guess since my paradigm is borrowed from windows explorer, why not continue with it. when you click on a 'folder' you get its view in the right pane. when you click another folder, the right pane view is replaced by the current selected folder, leaving you with only one view at a time. this way your desktop doesnt get cluttered with open folders. you can also explicitly open a folder view in its own window, and there is a taskbar to show you which windows are open. so i guess this would be added to the already in place task bar.

then maybe you would be able to save a number of screen view snapshots for recall via key combo.

perhaps a sequence editor could be shown in the tree as somehow associated with its target

i did imagine one tree list for the whole session, not a new tree for each mux.

maybe the mulab browser could be rolled into it as well, making it a one stop place for everything. and maybe you could hide it too.

i dont know if i made a good answer for your requirements there.

good idea, I like it

Adobe acrobat side bar shows images of the pages in different ways. The thing is, how much can you really see in a small thumbnail to really distinguish and understand what you are looking for.
FL Plugin Picker is a great alternative that could expanded to other objects.

Although i much like the vibe of showing the MUX in a tree list view for certain tasks, i still don't see how you see it wrt opening editors. Ok, i understood what you wrote about the left and right pane, but if you see this in the left pane


...
+ PolySynth
  Osc(1)
  Osc(2)
  ADSR(1)
  ADSR(2)
  LFO(1)
  LFO(2)
...


then how do you know which is which?
And you can't edit the connections.
So what's the big practical benefit of opening editors this way instead of opening them from the deep editor?



I think a MUX tree list view is a very interesting thing and i tend to relate it to the general browser we wish.
Then each module in the tree list will be right-clickable for its context menu and so the "Edit" function will be there so that's already a big part of what you describe right?

But then the original topic remains:

Imagine we have 12 open editor windows, some sequence editors, some module editors etc. Now if i understand well you're not happy enough with Ctrl Tab to switch to the right editor window, right? You want a 'better' way to switch between the open windows, right? The most 'instant' solution i can imagine is to indeed keep them as buttons on the window dock even if they're not hidden. So wrt this topic i tend to look into something like a hybrid taskbar/tab panel. Eventually spiced with mini pictures of the window (cfr OSX dock, plugin picker, etc...)

which is which? sorry i dont follow.

you dont need this to edit connections, just to get you where youre going.

the benefit is you can jump between 'unrelated' parts of the program



im really only trying to get around easier. whatever other function you can fit in there is a plus.



yeah this is fine with me. i envisioned the tree view in addition to an enhanced task bar.

If you only see names like Adsr(1) and Adsr(2) then how do you know which adsr you want to edit, when you don't see the context i.e. the modular editor. Of course you could rename things but we're looking for a solution that is instant and easy.

Anyway, i let the idea float a bit.
There is something interesting in it.

I think the idea is if you've a MUX named "MUX(1)" and it contains "MUX(2)" and also "Plug(1)" and "Plug(2)", whilst "MUX(2)" contains "Plug(3)" and "Plug(4)", you'd be able to see exactly where "Plug(3)" was: it would be nested inside "MUX(2)" which would be nested inside "MUX(1)" in the tree view. There would be no ambiguity.

But if you have eg 2 Adsr modules in the same patch, then how can you see in the tree list which one is routed to the osc pitch (for example)

jo is saying if there are multiple modules of the same type and with ambiguous names within a mux you wont know which one is the one you want to edit just from the name. which is true, but then again maybe youd just need to select the mux from the tree and then double click the appropriate module in the right pane.

how about this: only module containers (or 'folders') like muxes or racks are displayed on the left pane, and module containers and modules ('folders' and 'files') are shown in the right pane. so in the left pane you choose your folder (mux,rack) and the right pane you choose your file (module, sequence editor?)

It'd be very handy for nested MUXs, that's for sure, where you currently have to open up a whole new window to get to individual components.

It'd be great IMO if the browser didn't just cover stuff on the drive, but things in the current session in this way.

Something like

<Drive optionbutton> <Session optionbutton>

up top, where if you select drive you get the usual folder trees and stuff, and in session you have trees that are something like:

Sequences
Audio files
Session components (i.e. session MUX)

I've not seen this before, but I think it'd be very cool.

Yeah, I can't see why plugs etc should be in the tree view - it's only for navigation to the parts you can't easily see and gives greater understanding than a bunch of scattered windows or buttons on the taskbar. It's job is only to show containment of spaces that hold other things. OK, so you then couldn't see without going there that "MUX(2)" contained "Plug(3)" -- but that's like Windows Explorer: you don't know what files are in a folder (as opposed to other folders) until you make that the current folder.

It's definitely quite important to get this right with MUX going standalone.

oh yeah i forgot about that... haha maybe the browser could be a draw to mulab, not included in the mux vst

jo i hope that adding a browser doesnt feel like a defeat to you, since you say it should ideally be part of the OS instead of the software. i see it as necessary. i must say that the windows disk browser is (to me) extremely efficient in its visual feedback and also extremely useful for folder navigation.

i can tell youre a mac person at heart with your tidy interfaces and minimal style. does the thought of a built in browser offend your design sensibilities? just kidding

ooh the browser could easily be extended to display keymapping facilities too! too much?