Hub has not arrived yet, but I downloaded the editor to have a look
editor looks slick, and is really easy to use.
a could of suggestions:
a) could you change the pipe properties into an ‘inspector panel’ rather than it being a dialog
(this would not only be much quicker to change properties, but also if you wanted to review settings… since its a single click, rather than having to bring up the dialog then closing it)
b) right click on pipe processors, remove ( i know you can press delete)
(actually this is not needed if (a), as you wont need a context menu )
c) highlight insert position
so when you are dropping a modifier into a chain, you get a + , and depending on if you are in the first half or second half of existing, it will put it before or after that node. if would be cool if in the UI you could highlight where it was going to go
(often UIs put a little red line or something in between the 2 nodes where its going to get inserted)
p.s. not sure how you want to handle suggestions, is it better to post them here as we go along, or would you prefer we gather them up for the ‘final review’?!
The editor really works well (and intuitive) and has a well done general layout!
according thetechnobears suggestions:
a) yes! would be great!
b) on MAC: only fn+backspace deletes pipe processor. right click AND just backspace would be great supporting the workflow of mouse and keyboad focussed people.
c) yes!
I would suggest:
better highlighting currently selected pipe processor in main window. The orange works on the grey objects, but is very week on the yellow ones. More contrast on highlight would improve working with dimmed Monitor, as well.
Currently you can move the modifiers in main window by drag and drop. Moving whole chains by drangging and dropping their corresponding input would be great (especially when working on a bigger patch with multiple functions/routings). Right now you have to rebuild the chain you want to move and then delete the old chain.
This is a great suggestion. I do imagine once you start building more complex patches the current dialog flow could become a bottleneck. Which position in your opinion would be best for the ispector panel?
At this point is hard to imagine not having context menu at all. We will get back to this once the Editor is mature enough.
I guess even a whitespace should be enough for the indication. We will try some different option and pick the most natural one.
The final review should be written more from the use-cases perspective, e.g. Midihub has the “Y” feature so I can achieve “Z”, Midihub is missing “B”, so I can’t do “X”, and so on.
Backspace key for deleting the pipes and the Delete option in the context menu will be added in the next update.
Highlighting is a bit different per OS basis. We will try to find a most universal option. Thanks for pointing this out.
Of course multi-selection drag and drop is doable. The only concern is to implement everything so, that it would be possible to use the Editor with the mouse only - additional whitespace between pipes will be necessary.
As the grid is fixed copying and pasting is a bit complex. Maybe dragging the selected pipes using the right mouse button could make a copy of them. What do you think?
OK, then what about staying with the system (just can speak for MAC now) shortcuts and implement:
alt+drag and drop = copy
But if the aim is mouse only in general, then the right-click + drag and drop = copy is fine… but then could be tricky when also adding the idea of right-click = delete object
Context menu appears only after releasing the mouse button, so it’s possible to cover both functionalities. Also ALT + Drag could be supported too. Maybe others will have some suggestions regarding this.
It would be helpful if you could control more of the interface using the keyboard - i.e. cursor keys to move selected tile as well as keyboard copy and paste (in addition to the Alt key copy).
Also, how about assigning the Backspace key to delete tile as well as Delete? Otherwise on Mac laptop keyboards you have to hold down Fn which is a bit inconvenient.
Otherwise the editor is really well laid out and very straightforward to use!
I like how it seems to hold the size of subwindows after starting a new session. Nice!
Maybe have the pipes subwindows show all the pipes on first use? I got a bit confused for a second trying to find where the “exit” pipes were.
got it controlling an ambika hardware synth and ableton vst synth at same time … very tight … nice to make chords with the transpose modifer
it would be cool if the note transpose could be heard as you are choosing it rather than only after you click it …
i also found it a little unintuitive in terms of deleting modifiers … seems like it would be best to just be able to delete them with the backspace key ( i’m on mac )
i think that it would be amazing if there were an arpeggiator and some relative scale functions in the modifers …
perhaps having multiple arpeggios or even step sequences going out from the ports at different times but in same scale to different machines …
i haven’t put clock into it yet but will try that later with my mpc …
just scratching the surface here on first play
overall the midihub editor feels like a great start and is intuitive enough … maybe the virtual port thing could be a little better explained it took me a while to get it ( perhaps i am a little dumb though i found it myself just making another pipe with the same input ( midi A ) and assigning the out put to another midi channel instead at first …
i think the left with the others is fine… its a bit cramped with help+description
BUT I can see myself hiding the description and help panels once I know that things do, and then this is the most natural place for it to be.
but I guess this is just the default no? as users can dock the toolbars as they see fit…
a coupe of other small things
as you can only have one document open at a time edit->show tab bar is not required ?!
menu option for show “toolbar”,
(I hid it, and it took me a while to realise the way to get it back was to click on the pipes toolbar to get the context menu … it should also probably be “Toolbar” (case) (or perhaps Main Toolbar , these others are toolbars too?!)
pipes ‘reflow’ width
its a slight pity the pipes toolbar does not ‘reflow’ if you make it wider,
if it did, then it might be natural to have the ‘help’ underneath this toolbar (or even the inspector!?)
I can see why perhaps this isn’t the case, as your also using it for grouping…
perhaps you could allow it to reflow to 4 columns wide, but retain the vertical grouping.
alternatively fixed 3 or 4 wide seems to work nicely, with context help underneath (with 2 its a bit narrow)
keyboard shortcut to show/hide description and help (useful if im by default hiding them)
Thanks! We will introduce the “responsive” aspect later on.
Point taken. We are still discussing the “inspector pane” suggestion made by @thetechnobear, but it is already clear that ditching the dialog workflow would highly improve the overall UX solving this issue too.
Backspace for deleting modifiers will be introduced in the next update (next week at the latest).
This is actually already available with either alt or ctrl + dragging, except for input pipes which can’t be repositioned at the moment, but we’ll consider removing this constraint in future versions.
There’s not enough flash storage space available on the device to store the descriptions with the preset, but they’re stored in .mhp files.
Given this HW constraint, the description should get cleared after another preset is loaded, and before that, the Editor should prompt a warning and give a chance to disconnect from the device and save the original contents to .mhp file, if the description was modified. I’ll register this issue on the MH Roadmap board.
first thing i realised… I need longer midi cables… no software solution for that one
but a couple of other things for the editor
a) when you do store, can we get a bit of positive feedback its happened.
its so quick, I find myself not knowing if its done anything, so do it again…
Im not quite sure what ‘in sync’ means down on the status bar… does that mean the editor is showing whats on the device?
(because it doesn’t seem to go ‘out of sync’ when I change the contents of the editor, and before i send it again!)
b) I like the store/recall icons, but the arrows are a bit small, so differentiating them is not perhaps as clear as it could be … perhaps bigger arrows, different colours?
d) midi ‘debug’
this one is ambitious perhaps
I think it would be really handy if we could see midi messages in the editor.
a kind of midi log, so you can see whats going on each port (in and out)
its sometimes really useful for creating/debugging setups, if you can see midi is flowing thru.
(even longer term, this also potentially opens up some interesting UI possibilities, where you could debug your pipes… or use some kind of midi learn, e.g if you wanted to select CCs in the editor from your keyboard)
Yes, the storing and loading happens nearly instantly, there’s a progress bar dialog appearing, but it’s just too fast. It may make sense to simply have a visual indicator somewhere in the toolbar whether current state was stored to the device or was it modified since last storage.
Same for ‘in sync’ - after every action you make to the pipelines, the state is updated on the device, so it goes through a ‘syncing’ state, but this is also too fast to notice. It might make sense to not display this information, there’s an error popping up in case connection is lost anyway.
We’ll note your feedback on the store / load buttons, we’ll see how we can make it clearer.
On MIDI monitoring - it should be doable, but we’d have to see how well it does under maximum load. I was considering the options for adding support for this as well. What do you think about a Monitor pipe as an output pipe? It could also have a number as a parameter for the log id to log to. Having a COM USB port in the device instead of using USB MIDI for communication with the editor might help for this, but COM is a bit painful on Windows to set up.
Ideally, Id like to see whats going on on all ports…
my thoughts was only have it being sent when you actually have the debug window open.
perhaps if there is a huge amount of data, then it could be throttled?
(once there is alot of data, your going to find it difficult to look at the data anyway)
another possibility to reduce data, is to allow have some kind of filter, say only looking at note events… usually this is done client side, but i guess you could do on the hub to reduce data flow.
does that mean the devices is reflecting your changes before you do ‘store’?
(id assumed you had to store the change for it to happen )
)
Yes, you’re welcome to share your feedback as you go along.
Maybe others will have some suggestions regarding this.