Re: [yoshimi-user] More MIDI controllers - Info as promised

  • From: Will J Godfrey <WillGodfrey@xxxxxxxxxxxxxxx>
  • To: yoshimi-user@xxxxxxxxxxxxxxxxxxxxx
  • Date: Thu, 14 Oct 2010 20:30:09 +0100

On Thu, 14 Oct 2010 09:59:28 +1100
cal <cal@xxxxxxxxxxxx> wrote:

On 14/10/10 09:44, Will J Godfrey wrote:
On Thu, 14 Oct 2010 02:16:41 +0400
alex stone<compose59@xxxxxxxxx> wrote:

On Thu, Oct 14, 2010 at 2:14 AM, cal<cal@xxxxxxxxxxxx> wrote:
On 14/10/10 09:03, Will J Godfrey wrote:
[ ... ]
Talking about MIDI controllers in general, there is one that I've been
interested that simply has not been practical up till now, and that is
Program
Change.

Yes!! That's the big one I want too!

Recently, while working on a new composition I discovered that now, you
can
indeed, change voice patches in a non sounding channel while others are
sounding. You only get a slight disturbance in the sound if it is one of
the
very large patches that you are loading.

Very interesting, and suggests that program change implementation might
not be
as problematic as I've been imagining.

This means it is practical to do both voice and voice bank changes
on-the-fly.
There aren't many soft or hard synths that can do that! With some care
and
thought, while still only having 16 channels you can have a *lot* more
voices - 16384 in theory :)

I don't have any idea how much effort that would take to implement, and
I'm
quite aware that our long-suffering dev (yes, that's you Cal) can only
work on
a limited set of priorities at any time, so please regard it as a 'that
would be
nice' rather than a 'the sky will fall without this'.

P.S.
No I'm not planning on creating new patches to fill all those slots :P

... which does remind me of one small point needing consideration - for
managing
bank/program changes, I do believe it'd be simpler if the number of banks
and the
number of programs per bank was limited to 128. Currently the number of
instruments (or programs) per bank is 160. You can do a multi-byte
program change
to accoomodate> 128, but it'd probably be easier if to use single byte
with the
128 size limits.

cheers.

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2& L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
yoshimi-user mailing list
yoshimi-user@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/yoshimi-user


Cal, this would certainly fit with standard midi practise. 128x128 is
a lot of patches. :)

Alex.


I would agree with this, and suggest that in order to preserve backwards
compatibility the actual bank structure should remain exactly as it is with
the addition that patches numbered 0129 - 0160 are shaded a different
colour.
When working from a MIDI command Yoshimi should simply use the numbers 0001
- 0128. If there is no patch at the selected slot, abort the operation and
leave
the voice as it was.

This enables you to still work with existing bank sets, and also re-order
patches or even move them to other banks (load up to 16 patches - change
bank -
resave)

Currently there is no numbering system for banks, so bank selection could
be by
simply counting through the directories that are present. Number prefix
could
be added later if it was thought useful.

Your thoughts & experience here are valuable. I've thought about the
possibilities,
but haven't really thought through the practicalities. I agree, the existing
bank
management should remain unchanged. One approach I've been contemplating is
to add
a layer of bank/program associations over the top, ie another gui panel to
present
the midi control view of bank/program associations. So far that's just fuzzy
contemplation though, so suggestions are welcome.


If I have time tomorrow, I'll do some more tests to see how busy I can get
Yoshimi while making patch changes and see if I can find a pattern to the
ones
that sound while changing

Cool.

Hmmm. Just noticed I have 126 of my own patches - maybe it's time I thought
about splitting them up :o

... or maybe just giving some thought to which ones might be better moved to a
<128 slot. Don't get too industrious until we can firm up the overall approach
though.

cheers.

Rolls up sleeves - again!

The comments below refer to working on 0.060-pre2. While 0.058.1 seems
fractionally poorer that might be my imagination :)

Machine is 64bit athlon dual core 2.9GHz, debian etch ... ish.

First the bad news. Every patch that uses padsynth will interrupt the sound and
usually throw a single Xrun.

This is not as bad as it seems and is understandable. From info that Paul
originally gave out... Add & Sub build samples on the fly, but Pad creates a
perfect loop-able bufferfull *as* *it* *is* *loaded*. Clearly then there is a
significant overhead that can't be accommodated within one jack frame, so to be
effective the generation process would have to be split up or put in a low
priority thread - assuming that's possible.

However,

Simple Add/Sub single voice patches always load silently. The more voice parts
they have the more likely they are to interrupt the sounds, sometimes with the
briefest of crackles, sometimes more - up and including an Xrun. If you
normally see a delay as a patch loads, then it will interrupt the audio and the
length of the interruption will relate directly to the time it takes the patch
to load (is there a file system issue here maybe).

My initial tests were with a continuous pure sine wave on channel 1 while
loading patches into channel 2 - don't forget it needs to be active too :)
Like this any slightest defect shows up.

Later, I did the same tests, but with a 5 channel song running as well and
switching around in channel 6. The defects were actually *less* noticeable, and
when I also included a qsynth drum track and cunningly timed the voice changes
to coincide with the beat, most of the minor glitches were hidden - you still
won't succeed with Master Synth though :P

The point of that last bit is that I think, even without perfect silence all
the time, the whole idea is still both viable and useful.

I can certainly see the attractiveness of the separate, but related MIDI GUI
overlay, but would think it a good idea at first just to install the MIDI
hooks, and give us testicles (oops) testers a chance to break it :)

--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.


Other related posts: