Instrument Sets
OOM has a powerful feature called instruments sets. This is a complete file you save for each instrument you choose to build.
By default, OOM has 3 .idfs in the instruments directory. These are GM, GS, and XG.
This wiki page describes the function of the instrument set, and how to create your own. Our working environments here at the OpenOctaveProject involve almost exclusive use of LinuxSampler, with large sample libraries, so we've added a section, detailing the use of our LS automated Import Engine.
This page contains the following sections:
- Instrument Set Manager
- Create an Instrument
- LinuxSampler and OOM
- Controller selection per Instrument Set
OOM has an fundamental midi structure that relies on a instrument set.
There are default instrument sets in OOM, but the Instrument Sets Manager enables the user to build their own instruments sets, according to requirements. This window is a list of current instrument sets built by the user.
In the picture below, as an example, and as well as the default sets, there are 3 complete orchestral groups of instrument sets, 28, 40, and 128, so the number of sets you can create is, well, unlimited.
OOM uses the *.idf format for instrument sets, and you can set the default directory to store your sets in the Global Settings menu.
When you create ports in the Midi Port Manager, you'll use one of these instrument sets as part of the port, and in the track, the groups and patches sets you've built will appear in the track's Patch List drop down list. Be sure to save your instrument set after building it, and using common sense when naming your set. No 2 sets can have the same name, and OOM will attempt to add an integer if you do so.
To start the process, we go to the Midi menu, and select the Edit Instrument option. A popup window will open that looks like this:
The sections of the Instrument Set manager are as follows:
The Instrument list is a complete view of all the instrument sets (.idf) you have in the your nominated instrument set directory. The OOM default is:
~/.config/OOMidi/instruments
The right hand panel of the Instrument set window has 3 tabs, Patch, Controller and sysex:
**The Patches Panel**
**The Controller Panel**
**The Sysex Panel**
To create an instrument set, select New, then add a name of your choice. We've called our instrument test1. It's now added to our instrument set list.
We then move to the Patch tab panel on the right for our new instrument set, and create a group.
Click on the New Group button.
We select the new group then in the properties text box to the right, we name the group. We've called this one Violins.
Now we can add patches to the group.
Click on the New Patch button.
The patch is created, as a subset of the group directory.
We want to name our patch, but importantly we also want to assign MSB bank, LSB bank, and a patch number that is specific to this patch.
Our new patch is created and named. If you're building a bank of multiple patches, then as you add a new patch and name it, OOM will automatically give the new patch the next number in sequence. The MSB and LSB banks will remain the same. This will save you time, as it has done for us, when building large patch sets.
You can add new groups to the same instrument set as you want, and add patches to any group. Bank and patch number are fixed to patches, not groups, so you can mix them up if you wish.
User Tip. Our experience has been that a little forethought in laying out groups and patches, and keeping the creation and number consistent within a group makes for a better end result, and if necessary, easier to debug.
Make sure you save your instrument set.
You will be prompted to do this.
You can now build more instrument sets to your requirements.
By default, Instrument Sets are stored in ~/.config/OOMidi/Instruments. It's recommended you keep this as it is, but you can change it if required, in the Global Settings menu, at the bottom of the MIDI tab.
One of the more thankless tasks in setting up a big template is creating midi instrument maps, across more than one application. This is not only time consuming, but prone to error, as users have to replicate maps across apps, and the debugging process can often take as long as the map building itself. In OOM, we've built a much more robust framework for using, and sending and receiving LSCP messages, using LinuxSampler's own .lscp format, to reduce the work involved.
The process works as follows: The user creates a .lscp file, consisting of midi instrument maps for all their sample libraries, in both gig and SFZ formats if that's what they have, adds midi and audio devices, with the required numbers of ports for each, and channels, in which gig files are loaded and unloaded. This is a normal LS operation, and the user should end with the .lscp of their choice, complete with all the necessary elements and functions.
We then open OOM, and in the Midi menu, select Edit Instrument . The following dialog pops up.
At the bottom the popup is a button marked import instruments . Press the button, and a further dialog opens.
This is your window into the automated engine we've built to directly import your .lscp midi instrument maps into OOM, and automatically create Linuxsampler .idf instrument files for OOM.
The elements in the window, and their functions, are:
These controls are the netcat and list functions to directly communicate with the LS server. As for any client that communicates with LS, the host name and port number are required, and we've used the LS defaults in this example, as this will be the case for most users. On the right is the list instruments button, which will display the entire list of instruments OOM has found, from reading the midi instrument maps loaded in the LS server. (Your loaded .lscp file)
These 2 value boxes are to regulate the import process, and can be set by the user to control how quickly, and how many times, the import function will search for, and attempt to extract the necessary information from the gig file related to the instrument map.
The first box, Wait Timeout , sets the number of seconds between each retry.
The second box, Retries, determines the number of attempts made.
We put these in for users, as no two of us will have exactly the same hardware, and speed of drive read, and CPU speed, will vary. If you're on a slower machine, then higher numbers will give the import function more chance of success the first time around, but if your import doesn't work the first time, simply select the instrument from the list, and import again. For those with faster machines, an example being 4 core, SSD sample lib drives, more RAM, etc, you can lower these numbers. Either way, you have the means to regulate the import process to your specific needs, and the chance to re-import the same file information, if the import doesn't work the first time. (Which is possible with very large gig files, or those whose information is a little tougher to read, and translate)
This is your entire list of instruments read from your LS server lscp file instance. You can pick and choose in this list, by checking and unchecking boxes, which instruments you wish to import. The list works for multiple selections too, so if you're confident that your hardware is up to the task, you can check more than one.
These are the controls to manage your import process.
The import button starts the import process, after you've selected an instrument, or instruments, from your list. Once the import is complete, you press the save button to create an .idf from that import. The close button closes the dialog.
It's essential to note at this point, the use of ON_DEMAND_HOLD in LS when building your maps. The ON_DEMAND_HOLD function serves an important purpose for users who write, and add program changes to, sequencer based projects. User familiar with LS will know that as each patch is added to the project, LS loads that patch in a channel, and holds the pre-sample portion for it in RAM. This means we can use a series of patches in a channel and switch between them more or less instantly. It also means that LS RAM usage is steadily increased, the more patches we add, until we either have to restart LS, or run out of RAM, if the size of your library, and the pre-sample amounts for each gig file exceed the amount of RAM you have installed.
The Import function in OOM "tells" LS to load gig files, which it then reads from, creating your .idf, and extracting the keyrange and keyswitch information. Users are advised to keep an eye on RAM usage if they intend to import big midi instrument maps, an instrument at a time. When you reach the safe limit for your currently installed RAM, then close the dialog in OOM, close OOM itself, restart LS, open OOM, and continue with your next set of instrument imports. When you do this is dependent on how much RAM you have installed, and how big your sample library is. Common sense should prevail, as the import function, once used for your entire sample library instruments, gives you a complete set for OOM, and the import function in the future may only be needed for minor adjustments, or modest additions to your library.
Once the .idf is created, you'll have not only a mirror of the instrument from your .lscp file midi instrument map, but in the Performer, the keyrange and any keyswitches for the imported gig file info will appear in the vertical keyboard, next to the Performer main canvas.
These are updated in real-time as you switch program changes during playback, so if you have program changes with different ranges added to your timeline, you'll have an instant reminder of the range and key-switch info for that loaded patch. Highly useful for those with large sample libs, who can't quite remember the information for a rarely used patch, or just as importantly, the ranges of, for example, percussion instruments in gig files that have multiple areas on the keyboard, that are mapped in collections.
When your instrument is being created, or you wish to edit it further, you can select it and make your changes.
In the controller panel, you'll see a complete list of all midi CC controllers, and a window you can add selected CC's in. Any CC's you add will appear in a list when you add a new CC lane to the Performer Canvas, so it's a good idea to add the CC's you think you'll use per Instrument Set. Our 1st Violins, for example, have Modulation controllable patches, so the 1st violins Instrument Set should include this CC. The Triangle Instrument Set has no need of a Modulation CC, so we don't include it there, to ensure our Instrument Sets only display in the menu those CC's we're using for a given track, and importantly, the user is not scrolling up and down the entire list, each time they want to add a lane to the Performer.
The OOM LS import function was created specifically to reduce the manual work involved in setting up mirrored instrument maps across LinuxSampler and OOM, and was designed and built in-house, by the OpenOctaveTeam.
Work in progress...