It could be created a ttl parser into frontend layer. But it will be just used for visual representation.
If you want to make any changes, as changing parameter value or adding a plugin, and you only want to change the .ttl file, it will be necessary to load all entire pedalboard for each micro change, at least using mod-host.
The architecture changes will not change the API behavior, so it’s completely plausible working on parallel.
Is the pedalboard.ttl file format documented somewhere?
TTL (Turtle, RDF 1.1 Turtle) is a serialization format for Resource Description Framework (RDF, RDF 1.1 Primer) data, both standardized by the World Wide Web Consortium (W3C).
RDF is also used by the LV2 plugin standard to describe the plugin metadata like name, description, ports, etc.
The content (pedalboard description and configuration) uses a RDF vocabulary which is specific for MOD.
When parsing the TTL file I suggest to reuse existing functionality like RDF.JS (https://rdf.js.org/) or similar RDF libraries which exist for all majpr programming libraries, as there are many subleties in RDF and those libraries handle all they underlying nitty gritty details.
Any representation of the RDF data in a MOD-specific data structure can be based on that low-level reading and parsing using one of those libraries.
Hm, looks like pedalboards are actually not represented in RDF after all, just the plugin metadata.
Pedalboards seem to be stored as JSON, see this example:
https://api.moddevices.com/v2/pedalboards/652ab89ddb78bd993a1c0eb2/
While LV2 defintively uses RDF for meta data, there is also a JSON representation available from the MOD API, e.g. here:
https://api.moddevices.com/v2/lv2/plugins?uri_base64=aHR0cDovL2Ryb2JpbGxhLm5ldC9wbHVnaW5zL2ZvbXAvYXV0b3dhaA%3D%3D
Oops… “back to bed”…
I have local test-changes-for-fun adding client-side websocket debug info console logging for the Windows MOD app. It doesn’t look like I can attach the screen capture to a forum post, however.
Use an image-hosting service like imgur.
(maybe not ideal for the indefinite future, but it saves the forum having to allow the upload and saving of a lot of data)
I’ve raised your trust level, you should be able to attach a picture now
Maybe I am missing something, but is not that websocket communication already visible in chrome F12 debug menu without any additional code changes? At least I see that data flow on my hardware MDX webui:
You’re absolutely right about that. It’s just a first step of getting a bit of middleware into the websocket API; I might want to create some kind of visualization for it, or even just filter out the ping/pong & stats. A tool to help my understand and document the protocol outside of the code itself.
I am sorry, I wasn’t clear. When I told that
I was talking that with TTL files it would be only used to get the pedalboard state, and not for change the pedalboard stage.
If you access the pedalboard path, you can see some TTL files. For instance, when I created a pedalboard locally, it creates the following files:
The pedalboard data is saved into a TTL file, while snapshots are saved into a .json file.
Related to the json data that you shared, probably the mod team shares the pedalboard as .json because it is the most usual format for sharing over internet.
Well done for finding this! What I couldnt work out tho was where are the cables in the json - I can see it has an autowah, a shiroverb (an array of fx) and has 35 connections - but I can’t work out where it says what connects to what
Here is my first attempt at a sort of mobile UI for the mod - using the data @jetztgradnet found - its a expo.dev “Snack” a prototyping environment for React Native - I think I’ve come to the conclusion that full pedalboard construction (as in connecting pedals to one another) is not really possible on a mobile phone, however, tweaking the settings of the various pedals in in the board should be do-able.
Cool!
I had a quick look at it online.
It reads a “pedalboard.json”, which I guess should be received from the dwarf. This json contains an href to a descriptor of each plugin used, which you can use to handle the plugin parameters
Simple but really effective! Hope to see more soon
Z
Sounds cool. Not very great to found out that you forgot to map some parameter when it is too late.
Wonder how to use it with a real device.
Great job @steve!
For me, this small step demonstrates a moment that I think can have a big impact going forward. I think there’s a lot of room to experiment with utility-style applications that can interact with a MOD device or application, and potentially provide solutions for many long-standing user wishes. Examples of things I think could work:
I played around with your demo for a moment and am happy to test and provide technical direction where I can for these efforts. I have some familiarity with the pedalboard API and file formats and can help brainstorm ideas for implementations if you want to try things out.
this.
yes.
I’m really looking forward to getting some personal issues here straightened out and getting back to this. I can see that I was just scratching the surface of the entire effects chain, and this adds another layer of possibilities that is absolutely mind boggling.
