Yes, the changes are in real time, in volatile memory. Storing writes the current contents to flash memory, so it’s available on turning the device back on.
So basically instead of placing the monitor output ports, you’d like to see what is coming in on each input and output port?
exactly, this is not only useful for debugging modifiers, but also you can see if you have hardware plugged into the right ports, or if its sending data…
(btw: you’ll probably want to do something ‘special’ for clock, as obviously these can fill the screen quickly … i.e. its useful to know your receiving/sending them , but logging them every time tends to hide everything else !)
the pyramid allows you to see the midi coming in and out of it in one of the info screens, and ive been surprised how many times I’ve used it…trying to determine if something was incorrectly connected/configured, or even if the messages were a off for some reason.
oh, thats cool… really nice if you are interactively patching it 
another suggestion 
so my setup at the moment is something like (to simplify )
synth/controllers (in usb/din b-d) -> pyramid sequencer (in/out din A) -> synths (out din b-d,usb)
all is good, but what I noticed is that ideally, when i changed preset (or when hub turns on) ,
Id like some midi messages to be sent ‘automatically’
in particular.
a) send all notes off to the synths (cc 123, 0 ?)
(if the routing changes, and notes are active, you can get hung notes, due to note off not being sent… this mostly happens when your running a sequencer)
b) send local echo of to each synths (cc 122, 0 )
(basically because the sequencer is sending the data back to the synth
of course these are likely specific to me, but perhaps other setups, might want certain messages to be sent at startup/preset change.
A similar feature was also suggested here: https://community.blokas.io/t/feature-request-changing-presets-using-a-midi-controller/727/4, and captured in this card: https://trello.com/c/AxP47YqN/20-hardware-all-notes-off-when-switching-presets-paranormalpatroler. Will link in your suggestions too. Probably we should add some configurability to this behavior.
In the mean time, you can customize the button hold action in Device->Settinsg, so it sends the commands you want.
Hi there,
Here are a few early thoughts I had while testing the Midihub :
The Note remap could be indicated in Note instead of number. (Like C1 or A#3 instead of 0-127). I think it would make more sens but that’s my opinion…
Shouldn’t the “velocity amp” have negative values as well? It might be nice if it could work as a velocity limiter as well. Playing softlyyyyy is niiicee sometimes.
I think it would be nice to have the option to invert the selection on the Filter Pipe. What I mean by that, is that I tend to filter “everything but one channel” for exemple, and have to click on every channel except the one I’ll be using. Maybe alt+click could tickle everything but what’s been clicked on?
Is there a way to send Midi Clock messages WITHOUT sending Start/Stop messages ? If that could be implemented in the Filter Pipe, that would be cool! (I’d like to clock and sequence synths with an external sequencer without starting the synth’s internal sequencer if that makes any sens)
Thanks,
Cheers
Maxime
yeah, this would be nice, though worth noting octave number is ambiguous, if note number 60 = c3 or c4
Some suggestions after reading the above and using the Editor extensively during the weekend:
Good point, noted, we can display both the raw MIDI note number and the note name.
Actually you can already attenuate with values between 0…1, values higher than 1 amplify. For example, to attenuate the signal 2 times, you should set the value to 1 / 2, so 0.5. Let us know whether this does what you’d like it to!
Noted the suggestion on our roadmap.
Not at the moment, start, stop and tempo sync messages are all considered ‘System Real Time’ messages. We can make the selections more granular however, not a problem. Will add a task for this to the roadmap. Is there anything else you’d like to be able to filter out in particular?
Great step! If possible it would be great to break it down as far as possible… and then maybe make a sub menu for “System real time” (=select everything) and then allow the user to select everything individual in the sub menu as well.
What is the OS you’re running the editor on? Does it happen while you keep it in the background with Midihub attached? Anything in particular you’re doing with MH? Because normally it shouldn’t be timing out, only if you disconnect the device without closing the editor first (which is ok), or there’s a bug somewhere.
Do you mean lit up for a few seconds, or for entire operation?
Will fix, added to roadmap.
Updated suggestion by MaximeGraf to include this too.
Rational numbers between 0 and 1 should attenuate the velocity, please try it out, and if it works well, we’ll add a comment to the dialog.
What is the OS you’re using? Where on your OS would you like by default to save the presets? Do others have any opinions on this?
I’m a bit reluctant to create folders on users’ computers, I wouldn’t like that myself. What could help however is for the Editor to memorize the last location that was used to save or load presets between runs.
We’re contemplating a solution for enabling MIDI mapping of all the pipe parameters, that will open one or two doors for functionality definitely.
Which OS is this? We’ll get it improved.
Good idea, could you please provide us with a few sample preset names you’d like to use? The memory space for this kind of information is limited, so we have to pick maximum character length at the golden middle between the space available and usefulness to the user.
Good idea, noted.
Would you like this to be written in the Settings dialog itself, or some other or additional location(s)?
You may already drag-copy pipes you’ve used by holding down alt or ctrl (depending on OS) and dragging one of the intended pipes to the location you’d like to paste it.
For regular copy paste shortcuts, would you like the paste command to duplicate the pipe at the some location as the source pipe?
The LEDs indicate MIDI activity flowing through the physical ports. Would you like ‘opposite’ or ‘negative’ logic to be applied for the activity to the LED indicating the current preset, and the LED to be normally lit in case there’s no activity?
i find the way of working to create something simple like 1IN->4OUT split ab bit unintuitive
why we have to create 4 Ins? It would be more logical to be able to connect 1 node to several others
a bit like this (different not related software here)
We’re considering the ‘free grid’ option for Midihub programming, however, first we chose to give the grid based layout a try and see how far we can get with it functionality wise, since its implementation lends itself to a lower memory footprint for the processor on the device.
However, we might switch to this kind of layout at some point in the future, but that could happen some time even after the public release.
What is the OS you’re running the editor on? Does it happen while you keep it in the background with Midihub attached? Anything in particular you’re doing with MH? Because normally it shouldn’t be timing out, only if you disconnect the device without closing the editor first (which is ok), or there’s a bug somewhere.
I’m running on Windows 10, latest update. I’ll try this with another computer just to check if it’s an issue with the laptop. It happens when I keep the Editor in the background with MH attached, yes.
Do you mean [have the LED] lit up for a few seconds, or for entire operation?
The LEDs indicate MIDI activity flowing through the physical ports. Would you like ‘opposite’ or ‘negative’ logic to be applied for the activity to the LED indicating the current preset, and the LED to be normally lit in case there’s no activity?
Since LEDs are purposefully used to indicate MIDI activity then I’d appreciate a momentary change in the LED to showcase the current preset, in the same manner as when using The Button. There ought to be a hardware indication of the change done via the Editor. Similarly, when changing Preset using The Button, the Editor also changes Preset.
Rational numbers between 0 and 1 should attenuate the velocity, please try it out, and if it works well, we’ll add a comment to the dialog.
Just took a look, you are of course right. If I my suggest to change the name from Velocity Amplification to Velocity Leveling or Velocity Scaling. It’s misleading as it does more than just amplify. Worst case scenario, make sure to add this info in the Context Help - should clear things up for new users and it’s a simple addition of text.
What is the OS you’re using? Where on your OS would you like by default to save the presets? Do others have any opinions on this? I’m a bit reluctant to create folders on users’ computers, I wouldn’t like that myself. What could help however is for the Editor to memorize the last location that was used to save or load presets between runs.
That could help. You don’t have to make a new folder necessarily, I just find it weird that I can’t save on the folder which is already created! Tried it on two computers and it says the same thing:
We’re contemplating a solution for enabling MIDI mapping of all the pipe parameters, that will open one or two doors for functionality definitely.
Yes please! Yes p l e a s e!
Mouseover. Infoboxes should stay on when my mouse hovers over a Pipe. It helps to see what each Pipe is doing. Message goes out way too fast.
Windows 10. It’s a bit of a pain to have to go back and forth with the mouse a few times to see what an edited Pipe does without opening it.
Good idea, could you please provide us with a few sample preset names you’d like to use? The memory space for this kind of information is limited, so we have to pick maximum character length at the golden middle between the space available and usefulness to the user.
Anything from “MyPreset99” to “Jazz Case Transpositions”. Personally I’d go for the latter. As a performer I’d like to be able to name my presets so that I know what I’m “packing” on the device when I go out on a gig, without having to sit down and look at all the pipes.
Would you like this to be written in the Settings dialog itself, or some other or additional location(s)?
I’d just add this info on the Settings page. It’s where you define the Long Press for The Button. You might as well add info that Short Press will scroll through Presets.
You may already drag-copy pipes you’ve used by holding down alt or ctrl (depending on OS) and dragging one of the intended pipes to the location you’d like to paste it.
Works for me. That’s all I needed. I just wanted to avoid having to redo a Pipe.
I would assume that Copy/Paste via keyboard would add it on the same location.
You should at least consider an intermediate situation, in which when sequential grids are using the same Input then you’d get something like this:
Yes, and if you find a way to have a sharing platform for the preset, that could be interesting for beginner users as well → just downloading and uploading “2 in 1 out merge” or “1 to 4 split”.
I don’t see this as an incredibly important part of the Midihub, but it may render it even more “user friendly” as in : you don’t even have to understand midi or bother patching your own hub to use it as a basic hub.
I did a few basic preset for myself so…
That’s also what I was thinking, this + a numbering for each line (So that if you want to split midi A in 16 channel you have a visual reference of where you’re at)
I think I’d like it better that having to draw lines going in every directions. Just my opinion tho.
Agreed ^
I like the grid/line UI. Keeps things tidy. I’d just like something that can visualize when things are coming from one specific Input or going out to a specific output.
I also thing the idea of adding numbered lines is good. Maybe Click+Hold+Move on the line number would allow you to move it up/down in order to organize the situation a bit. There is no option to move a complete line right now, if I’m not mistaken.
Stuff like these would be ideal for me:
a) Clever arrows
b) Allow for more clever visualization of the arrows by retaining the arrow space after the input and before the output. The issue here is what happens when a line has a different number of pipes than the rest, but that also seems easy to fix by extending the arrows after the pipes.
Just some ideas, as always.
So far I found the editor pretty good to work with.
Some very minor things I would find neat are:
a clearer UI distinction between MIDI, USB & VIRT (perhaps three different saturation levels for each port type)
a different color per port
perhaps even assignable colors or names for the input & output ports
I think these might help to see what’s going at first glance and to avoid routing mistakes.
A few things :
Is there anyway to have the Midihub auto connect to the computer/editor when plugged ? I found myself making up patches until I realize that the Midihub was plugged but not connected… not a big deal but a little frustrating (… I know I’m the one to blame here, but might be more userfriendly to auto connect, or to have a clear indication that you are making a patch on the editor only and not on the midihub itself. )
I kept thinking about this Velocity to CC etc, which would definitely be super cool.
I think that the same reflexion could apply to aftertouch and other non CC controller. Aftertouch to CC would make almost “any midi device” aftertouch responsive, and that would kick some serious ass !
Cheers,
Maxime
yeah, I kind of mentioned this before , as there was confusion on what the current ‘auto connect’ functionality does.
I think auto-connecting when the editor is started would be useful,
though connections also implies loading the current running preset (from the midihub) into the editor, don’t know if that has any nasty ‘side-effects’
