Cal, and fellow yoshimi users, i have a suggestion to put forward for
a robust "global" method of handling banks and patches, with one eye
on the eventual ability to trigger bank and patch changes from a
sequencer.
Over at the openoctaveproject, we're using a bank and patch format
called .idf (instrument definition file) to manage multiple sets of
banks and patches. We're doing this in a fairly big way, with many
dozens of idfs managing large sample libs, and their management and
use in openoctavemidi. I've been thinking about this for a while, and
i keep coming back to the notion that a "global" format for banks and
patches would suit not only us, but other apps too, in particular the
mighty Yoshimi, and other patch set based synths and samplers.
The .idf, inherited by openoctavemidi from Werner Schweer's original
muse codebase, is an independent file, that we "insert" into the midi
port chain, which then shows the bank and patch set for any track that
uses that idf. It's highly useful, robust, and enables users to
instantly add bank and patch changes to the openoctavemidi timeline
for a part in a track, reading the patches from our inhouse built
patch list function, and patch sequencer.
The point of this i guess is, if synths and samplers were to use a
common format, like an idf, then new users would only need to build
one set, and use it in any idf capable app, and developers of existing
and new synths and samplers would have an identifiable, and common
bank and patch set management system to work with, knowing it would be
consistent with multiple apps, and the all important sequencing use
that open their instruments to a much wider user base.
As i wrote a little while ago, i started building an idf to use
yoshimi from inside openoctavemidi, but stopped because we're not
quite at the "sequencer please trigger yoshimi bank and patch" stage
just yet. (I'm looking forward to this, to a degree that could
cheerfully be called the "spiffing" factor)
This may be a step too late in the current build and code process, but
if it isn't, maybe it's worth consideration in the spirit of
"globalising" elements of linux audio and midi workflow to attract
more users, and make the donkey work process of building multiple
identical bank and patch sets across multiple bank patch management
systems, a thing of the past.
I admit a vested interest here in smoothing the management of banks
and patches between Yoshimi and openoctavemidi (one idf to rule them
all, and build it once for all), but somewhat altruistically, i see
this as a potential plus for linux audio in general, and quite
possibly, a more efficient way of managing the loading of saved
instrument sets in jack session, as an example. (build the idf you
want, and tell jack session to load the idf for that session, as well
as make all the connections)
For using large sample sets, and extensive bank and patch sets, like
those in Yoshimi, the concept of using that bank and patch set in any
idf capable app appeals to me, not only for the fact i only have to
build it once, and use anywhere, but more practically, from the
perspective of many many years of having to build repetitive bank and
patch sets across multiple apps, simply because they didn't recognise
each other as the formats were different. As linux audio offers many
plusses over other operating systems for musicians, composers, etc,
imho, this one is an easy win to further enhance our linux toolset,
and strengthen our......'street cred'. :)
No doubt there are several flaws in this idea, including recoding when
it might not be worth it, but input is welcome on the concept of a
global instrument definition set that users will only need to create
once, and use in multiple apps, especially Yoshimi.
The idf works very well for us, so imho, it's a good place from which
to start a discussion.
An added note here, that in my use case, Yoshimi would figure in
playing soft pads, atmospheric sounds, and background crooning, in a
film or visual score environment, as well as experimentation with
conceptual mixing of orchestra and synth, so that has a bearing on my
idea as well, and where i'm coming from with this, using a midi and
audio sequencer (openoctavemidi) driven workflow.
Alex.