import of documents for auto-populating parameters

[markusschloesser]

An import of parameters based on tables from documents e.g. PDF, txt from manuals.
Gold standard is to "auto-build" a preset, but every little bit helps. So just enumerating possible parameters and categories would be helpful as well. I imagine parsing pdfs is not that easy, so even a row based imports could save time

[markusschloesser]

you now already have the import view for values, couldn't you just re use this for CC import as well? And just list the controls one after another? dragging stuff around is still a lot easier. BTW How do I drag from one page to another?

[TheTechnobear]

I've actually done this for projects (in completely unrelated field)

In my experience the pdf formats for specifications vary too widely for this to work.
this means you have to build a 'parser' for every instruments manual. (*)

as a 'one off' excercise, you spend as much time (invariably more) writing/testing that parser as you would to enter the data manually.
there are two exceptions (and reasons to do this still)

• when there are A LOT of parameters (e.g. many hundreds)
• when the specification changes frequently, and so you need to 'regenerate' the mapping.

unfortunatly, I think neither case applies here...
midi cc are limited to around 100, so only really is useful for something with extensive sysex implementation
once a synth is released its cc mapping is not going to change much, so its really a 'one off' process.

so I dont think its a good general approach, or something electra.one could do.

however, it is an approach I would personally use as a one-off, IF I can across something with a large specification.
but what I would do is use the 90/10 rule. Id hack something quickly that would get as much of the data as possible, even if it was not perfect and I needed a text editor to 'fix' it. then I'd convert this to an EIF.
(Ive did something similar to this when creating a pyramid def file for the Virus TI)

the point here is... its very specific and quick 'hack' its not something that would work in any other scenario, so it cannot be 'generalised' enough to make it useful in other scenarios/instruments.

---

(*) after a while, you do end up with some common code that you can 'raid' to use on new manuals, but they still invariably need adapting.

[markusschloesser]

very good and valid points. I thought that most tables in synth specs were pretty standardized, at least visually.
However I had my FS1R in mind and that one unfortunately has thousands of sysex parameters.
I do have the m4l IluvFS1R device, maybe I can midi learn the sysex from there