Examples for working with file system?

Hi guys.

Could you please point me into examples that illustrate working with MOD’s file system from LV2 plugin?
I was trying to find sources for midi player and audio player but strangely found nothing.

1 Like

You need only 2 things for this:

  1. handle filepaths on an atom input port (quite a few plugins do this, lv2/plugins/eg-sampler.lv2 at master · lv2/lv2 · GitHub is one example)
  2. set the file type that this filepath accepts (MOD specific extension)

the last one is as simple as these changes 01-filetypes.patch

available file types are listed in mod#fileTypes


Thank you for your answer, but exampler seems to use predefined list of filenames, and does not seem to illustrate how to list files or folders that can be uploaded, how midifile player plugin does.

I need to apologize in advance, I am a complete newbie in lv2 development at this point, and not even sure if my final goal is even achievable, still struggling with basics.

Probably I need to explain what I am hoping to do in the end, maybe you can give some advice, as I might not know enough to ask proper questions.

There is a guitar pedal out there, called “BeatBuddy”, it is a drum machine for guitarists, that allows playing drum loops, switching between song parts via a single footswitch. (Long press - start playing song or switch to next part loop, single tap - play fill corresponding loop, double tap - play outro and stop).

Considering that MOD already has plugins to produce drum sounds from midi input, I hope that I can make a plugin that will attempt to mimic BeatBuddy’s behavior, (let’s say, MeatMuddy, lol) but produce midi output instead of sounds, and use custom-uploaded midi loop sets from the MOD file system arranged in a way approximately as below:

  • midi-loops
    • SONG1_BLUES_IN_120bpm
      * Intro.mid
      * Part_1.mid
      * Part_1_fill.mid
      * Part_2.mid
      * Part_2_fill.mid
      * Outro.mid
    • SONG2_FUNK_IN_130bpm
      * Intro.mid
      * Part_1.mid
      * Part_1_fill.mid
      * Part_2.mid
      * Part_2_fill.mid
      * Outro.mid

Ideally, I should be able to choose the song folder (SONG1_BLUES_IN_120bpm, SONG2_FUNK_IN_130bpm) from the plugin interface, and be able to play loops from folder’s midi files, switching between files on the fly.

At this point I’ve managed to understand how to get midi input and controls from the ports and send some midi stuff to output, and build some basic plugins, but I am missing vital parts like playing/parsing midi files from filesystem and ability to list folders in plugin’s interface.

Midifile player seems to be ideal donor to s̶t̶e̶a̶l̶ borrow some code to cover these most cryptic topics, but could not find the sources yet.


I like the the idea of having this as a separate plugin and more flashed out.

Although I think that the majority of it is already doable. Did it kind of with this board.

The midi sequencer has presets which I used to be able to jump between drum loops with the device footswitches. What’s only missing is a direct selection of the preset index and midi-to-preset conversion.

The second part should be easy: convert the midi files (or xml) to the preset format (turtle)


Okay, what I was able to understand today by looking into network communication, it is not the plugin itself who returns list of the files to interface as I thought.

It is a javascript UI part getting list of files from device’s web server (https://github.com/moddevices/mod-ui/blob/master/mod/webserver.py)
by api urls http://modduox.local/files/list?types=midisong or http://modduox.local/files/list?types=midioop And this js ui passes chosen file’s path via websocket to the actual plugin.

API is able to list only files of certain types per predefined folders (_get_dir_and_extensions_for_filetype) , and cannot be used to list folders, therefore organizing files in folders (and choosing folder, not a file in plugin UI) as I want is not going to work, at least with a pretty ui without API modification.

Best thing I can do is probably to enumerate my midi loop sets and use just a regular stupid numeric control to choose between them, relying on the hand written notes to remember that “1” means funk in 120 bpm and “13” means waltz in 234.5 bpm.

Or, otherwise try scaling to use 6 input controls to choose separately intro, parts 1, 2, fills 1,2 and outro on per file basis, and store each such combination as a preset. Not very bad actually.


Hi sorry for the delayed response.

You are right, this is all not up for the plugin to do or implement.
The main deal is that these files are not on the user’s machine, but on a “remote” device which the web browser side has no access to directly.
Current architecture is a little weird compared to typical usecases, it is what we think works best given the conditions and restraints.
That being: the user needs to upload files before the plugin is able to see them, so made sense to organize them into folders, which we simply allow the plugin GUI to pick from.

If you really want to have folders and users picking from those folders, it is still all possible… if you do the entire work of managing it within the plugin (an uploader/manager that sends data to the DSP/plugin side to write on the device filesystem).
Or list the available files by sending messages from DSP to UI on request, as we allow arbitrary data to be passed around you can encode the entire thing as a base64 string or something.
Trying to go that route feels like over-engineering though, as things can get quite complex quite quickly.

Perhaps a more feasible approach is to let users create these files and send them to you, to be incorporated into the plugin as updates?


Still thinking over other things from your post, but regarding this particular part - it might be a copyright/licensing problem, when using third party vendor loops - something like groovemonkey midi loop collections (that is my main use case actually)

Quite a lot of them are paid, and I am not sure if including even the free packs to open source repo will be legal. That’s why it should be a user-defined content.