Add the way to change single instrument of currently-loaded bank on the fly.

[Wohlstand]

This will allow to use libADLMIDI directly how for OPL3 Bank Editor's backend to change instruments on the fly to test them, or give the ability to use libADLMIDI as VTS-plugin for the musical software.

• • [x] Stop to clean/resize the dynamical instruments data arrays. Instead, override them.
• • [x] Instread of direct access to the generated database, copy instruments of currently choosen embedded bank into dynamical array which is easy to patch.
• • [x] Make instruments store be pre-allocatable which will allow to avoid any reallocations in the real-time when sending instruments on the fly into over-GM range.
• • [x] Add the instrument structure (probably, copy-paste from wopl_file.h from the OPL3 Bank Editor the single-instrument structure) and the function to receive it's bank MSB/LSB, Patch number and type of the instrument (melodic or percussion).

[Wohlstand]

ADLMIDI must expose an instrument structure. This can be the structure from WOPL, but I propose to version it, so the instrument can get its futures updates freely without breaking any compatibility.

Yes, but copy it and call it differently, as WOPL's stuff is private in libADLMIDI.

It must provide an access to the OPL banks, read and write, and also search/list/add/remove. The bank will be identified by LSB+MSB+melodic/percussive.

Yes, banks are identifying by LSB+MSB+isDrumOrMelodic :+1:

The bank storage area will be a std::vector. This storage can be reserved to some desired capacity. The add method will have a flag which specifies if the storage is allowed to extend. If it's a call from hard-RT, storage must not be allowed to extend.

Some stuff I made on a side of libOPNMIDI and I gonna port that, I mean the function that initializes and cleans up the whole instruments store. I made it to don't re-allocate the store if size wasn't changed.

Unit testing must be added to check all this stuff works like it should.

That is nice, because remember, while we worked on hard-RT, we had lots of crashing crap on various things, include my phone, and that was mean: I wished to continue listen my musics on my phone, but epic fail: library is crashing...

[jpcima]

because remember, while we worked on hard-RT, we had lots of crashing crap on various things

Why are you talking about? I don't remember any such things :angel: :grin:

[Wohlstand]

Why are you talking about? I don't remember any such things angel grin

Anyway, the whole thing is great, when we have polished it :fox_face: :+1:

[jpcima]

One more question: does the basic unit of storage really has to be banks? Can it not be just instruments?

[Wohlstand]

Array that stores instruments - stores for all banks. The bank is recognizing by offset inside of this array, and then every instrument is finding by bankOffset + 0..127 (you also can see the drums offset)

[jpcima]

Sure but this is my point: it's wasteful. Say I allocate space for 2 banks. The limit to store a collection of arbitrary instruments in this, is 256 at best and 2 at worst (if instruments belong to different bank ids).

If going over storage limit must happen in a user interface and I must popup a warning message, the explanation will make little sense. (why can't I store more if I just have 2 instruments in?) (of course I choose the ridiculously small size for sake of explanation)

Instead of forcing to have blocks of 128 instruments, why not lookup the instrument, and if not existing: redirect to the global blank instrument which is only stored once somewhere.

[Wohlstand]

The reason of 256-blocks of instruments is that the library is designed to give MIDI interface for complete General-MIDI to just correctly play MIDI files through it. Having compactized storage will just give the extra map: LSB+MSB+PatchID+MelDrum, and then offset will be given to every instrument than to one of 128 block. Anyway, if needed to use library for few instruments for a plugin-role, then allow to allocate bank for specific count of instruments than for 256-instruments blocks.

[jpcima]

I examine the whole thing and I will give you a concrete solution to look at. I am not going to introduce a performance regression at program level, don't worry.

[jpcima]

I've created a draft API for banks and instruments. What do you think of it?

https://gist.github.com/jpcima/8afc0064fba09a1f3290245f878da4c8

The WOPL instrument is identical to this API, except for some things.

• version number
• name and rythm flags removed (not used)

The ADLMIDI_Bank object is a disguised iterator of the bank map.

Now there are also existing APIs which refer to banks (embedded ones). setBank getBanksCount getBankNames So the mixing of these APIs may create some confusion in users. I think it's a possibility to put new APIs under an adl_db_ prefix. (where db stands for dynamic banks)

[Wohlstand]

The RythmMode flag is only now unusable, but I gonna to use it when I will fix the rhyth-mode behavior in OPL3 Bank Editor to support it in ADLMIDI too. For now the Rythm-Mode thing is clunky and needs a rework I will begin after fixing of editor where hihats and cymbals not working on Nuked and on real OPL3... So, please keep the rhythm-mode flags for now, In nearest future I'll use them all...

And yeah, adl_db_ is a good strategy to easily separate API parts, and also, use my super-simple SDL Audio sample in pure C to validate the API is C-Valid :wink:

[loki666]

how is this one going?

[jpcima]

@loki666 the APIs are made, you have currently ability to inspect banks/create by means of adl_getBank, and go into instruments by adl_setInstrument/adl_getInstrument. The instruments are available as public structures to manipulate.

Two things to keep in mind of which I'm aware, about editing

• it does not recalculate the best 4op disposition of channels after an update
• neither does it recalculate the delays, until a simpler approximation can be implemented and tried. meanwhile, one can use the time consuming measurer code of OPL3BankEditor

[loki666]

ok thanks

[Wohlstand]

I think, this is also completed and working, that is using in ADLJack thing and others. Right?

[jpcima]

Yes, it's complete!

[Wohlstand]

Then, closing! :wink: