Re: [yoshimi-user] More MIDI controllers

  • From: alex stone <compose59@xxxxxxxxx>
  • To: cal <cal@xxxxxxxxxxxx>
  • Date: Thu, 14 Oct 2010 03:29:24 +0400

On Thu, Oct 14, 2010 at 2:59 AM, 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.

------------------------------------------------------------------------------
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


Just a note here. One problem with many apps, both opensource and
commercial is the notion of focus. Another window opening to access,
for example, loading patches on the fly whilst using a currently
loaded patch, may cede control. So if the user opens a new window, he
may find that his much cherished controller actions no longer work. I
know CCcontrollers are supposed to enact a single process, regardless
of which window is visible, if the app allows for specific and direct
controller association with a function or button/slider/etc, but not
all apps do this successfully.

Just a thought to add to the considerations.

Alex.

p.s. Will, if you have 126 patches, then they'd all fit in a single
standard midi bank, yes?

--
www.openoctave.org

midi-subscribe@xxxxxxxxxxxxxx
development-subscribe@xxxxxxxxxxxxxx


Other related posts: