Dear Blokas Team,
It would be most useful if the presets could be stored and loaded in a human readable and editable file format.
Using a text editor to modify a preset would allow for significantly faster editing of e.g. mappings and any reoccurring numbers in the preset.
For example, copying a large number of complicated pipes to another midi input with adapted mappings or other values would only take a few keystrokes instead of lots of clicks and knobs turning.
I am about to order my second Midihub today. It is very useful! But this is a real showstopper.
Please, pretty please, allow us to edit presets in a text editor!
With kindest regards,
Annaluise
I’d like to second Anneluise!
I’m not sure what sort of format might be used for export/import, but if it was something verbose like xml:
- I’d also like to see a “note” field for every pipeline to allow notes to be appended (even if they weren’t read by Midihub);
- because Midihub is so intuitive to setup in an experimental way, an old brain like mine comes back to a patch months later and can’t remember what the hell I was doing, particularly if was something tricksy like using one mapped LFO to modulate another
In the meantime, I shall return to my side project of trying to figure out how to decode .mhp files!
I wouldn’t call XML human readable or editable 
But indeed, text based import/export would allow various things currently impossible (like scripted creation) and overall nicer to those of us allergic to mice.
3 Likes
point taken!
as long as it’s parse-able I’d be happy
I support the idea !
While the app is great looking and user-friendly (and a great asset of the Midihub), the limit is the file format used to store configurations.
Obviously I would love to add more comments to my configurations, and interleaved with pipes, and be able to parse them automatically to check for errors and maybe generated them as suggested above.
It could be a set of external tools, or an upgrade of the file format (with the next gen Midihub).
Still, I love my Midihub and the software. Keep on good work !
XML is easy to read and very easy to edit too. Each instance of an XML tag is called an element. In an XML file, elements are arranged in a hierarchy, which means that elements can contain other elements. Very simple - even easier than code.
Here’s an example from my Pi media player
<sources>
<video>
<default pathversion="1"></default>
<source>
<name>Auto-mounted drives</name>
<path pathversion="1">/media/</path>
<allowsharing>true</allowsharing>
</source>
</video>
<music>
<default pathversion="1"></default>
<source>
<name>Auto-mounted drives</name>
<path pathversion="1">/media/</path>
<allowsharing>true</allowsharing>
</source>
</music>
<files>
<default pathversion="1"></default>
</files>
</sources>
Totally readable and easy to edit with a plain text editor.
@saji.bo
It could be a set of external tools, or an upgrade of the file format (with the next gen Midihub)
My thinking was based on knowing that the Midihub itself is kept quite light weight; I discovered early on that the Notes Panel has a character limit, for e.g.
SO I assume that adding an “info” pipe (to drop in here & there as an aide-memoire) would likely limit the bytes available for more functional stuff. Hence, if import/export functionality was added the the Editor with attachable notes capability only there, I’d be happy enough with that!
In the meantime, can someone at Blokas publish the protocol for how .mhp files are set out?
The .mhp format is not hard to reverse-engineer. If you intend to write a translator, it should be a piece of cake. Also the reason the Notes are short is because their length is coded in the header of the mhp, and is a fixed field, if I remember well.
Now for clarity, it is very convenient to store chains in smaller “modules” (can’t think of a better name). Each can have its own full length notes field. When the modules are appended to the current config, the textual notes are lost in the compound, but still available in the module.
For exemple, I have a module for clock management, and I can detail every chain and operation done on the clocks in comments. When I create a full set, I import the module, and others, then create specific chains if need.
I agree that the Info pipe would be a great addition !
Now for clarity, it is very convenient to store chains in smaller “modules” (can’t think of a better name). Each can have its own full length notes field. When the modules are appended to the current config, the textual notes are lost in the compound, but still available in the module.
Ha! that’s much more systematic than I’ve been! Most of my patches are “evolved” rather than designed. I must sit down and do things properly one of these days!
I did start reverse-engineering (yep, the notes are in the header) but got distracted by something else until @Annaluise raised this issue.
+1000! This would be incredibly helpful AND would 10x the power of the MidHub and editor by making it more easily hackable by the community. I’m a coder and I would personally love to code my own patches in Python and export them as text files.
This would be great, my angle is that in 10 years if Blokas are history or have moved on so far that they don’t care about this old device any more, well if there is no current software that supports the operating systems of the day, then this device becomes an expensive paperweight.
(@arcticAnalysis Welcome to Midihub forums!)
Others have expressed an interest in being able to interpret and maybe edit a patch.
Am I correct: You would like to have scripts to:
- read patch binaries to display them in human-readable form…
- edit/create them and…
- retrieve/save them to and from the device?
Number 3 is a new notion, I think.
I’d be interested to know @Blokas view on this.
btw:
I recall @Giedrius saying in earlier days that they might think of providing an API for Midihub, but maybe they’ve moved away from that.
The first two wishes strike me as more do-able and maybe could be done as a github project without extra Blokas work (just as the ZOIA Librarian.app was written by some ZOIA fans AFAIK without Empress having to spend time on it)
Thanks for the welcome : ) my midihub is in the post and I’m quite excited to get my hands on it.
As for this request, it’s not something i can even envisage using while there is such a useful GUI available now, and the fact that it’s just for setting up configurations that can be used in a computerless setup suits me just fine.
It’s more just to know that there is a way in the future to configure the device without official software, so that it doesn’t ever become redundant for the want of software.
I’m a software developer myself and clearly not the only coder, somebody could come up with something when the day comes just so long as the specification is available on how to achieve it.
We wouldn’t leave our community hanging if something is ever to happen to us. 
We’ll keep in mind that people are interested in such a feature, but at this time we don’t plan to do this for Midihub, as the binary format keeps changing from version to version as new features get added, it would also be an extra toll for us to keep the format publicly documented and up to date, also pretty much every update could break any tools people write.
2 Likes