Human readable (editable) file format

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 :sweat_smile:
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.

2 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.