AKJ, you are slashdotted!

Aaron & All,

My Keyboard Magazine piece on Making Music with Linux
was slashdotted today.

http://linux.slashdot.org/article.pl?sid=07/05/07/159250

And because the keyboardmag.com site went down
immediately, the article has been posted right in the
comments. And one reader wants you to sourceforge
your pymidichaos code...

""
I'd like to see the guy who was interviewed put his
python program up on sourceforge... it's neat and small
and could do with more exposure... currently, there are
precisely 4 links on Google for it, and one's in the
article and I haven't a clue what licence he's got for
it as there's nothing mentioned in the actual code or
anywhere... I really want to know what licence he plans
to let us use it under before I start messing with
it myself...
""

For all of you joining in, I interviewed Aaron for
this piece, and discussed the creation of his microtonal
music in the article.

-Carl

Carl Lumma wrote:
> Aaron & All,
> > My Keyboard Magazine piece on Making Music with Linux
> was slashdotted today.
> > http://linux.slashdot.org/article.pl?sid=07/05/07/159250
> > And because the keyboardmag.com site went down
> immediately, the article has been posted right in the
> comments. And one reader wants you to sourceforge
> your pymidichaos code...

I followed up on LADSPA (http://www.ladspa.org/). Rather like OSC, it looks like a vague low-level protocol that doesn't go as far as specifying pitch. But I checked out the example code and all the synthesizers take a frequency input. So, if anybody writes a microtonal-aware LADSPA host it'll be able to embed any plug-in that follows this convention.

The bad news is that the suggested higher-level protocol for synthesizers, DSSI (http://dssi.sourceforge.net/) does seem to imply a 128 note limit. Again, nothing about pitch is specified, but the specification is obviously incomplete so, again, I looked at the example code. The trivial_synth.c still uses a LADSPA framework with a frequency control. But it's controlled by ALSA events which I tracked down here:

http://www.alsa-project.org/alsa-doc/alsa-lib/structsnd__seq__ev__note.html

There's an unsigned char for "note" which of course means you can never get more than 256 notes and I'm sure most plugins will ignore everything beyond 128. There's also no "frequency" element so you have to specify tuning tables separately to the note-on, as with MIDI.

I don't know how settled this is, who we should complain to, or if it really matters. But for microtonal purposes a frequency in Hz is a much better control value than a note number. The note to frequency conversion should be handled in a MIDI abstraction layer, not in each synthesizer plugin. I hope we can agree on that.

Graham

Graham,

Yes, unfortunately it seems that the convention of most softsynths is
being followed by the LADSPA and DSSI plugins.

I would however be willing to bet that if you forwarded your comments
to the developers they might be considered in future releases. but who
knows for sure....it's worth a try, anyway. Maybe at the very least, a
fork could be developed.

Best,
Aaron.

--- In tuning@yahoogroups.com, Graham Breed <gbreed@...> wrote:
>
> Carl Lumma wrote:
> > Aaron & All,
> >
> > My Keyboard Magazine piece on Making Music with Linux
> > was slashdotted today.
> >
> > http://linux.slashdot.org/article.pl?sid=07/05/07/159250
> >
> > And because the keyboardmag.com site went down
> > immediately, the article has been posted right in the
> > comments. And one reader wants you to sourceforge
> > your pymidichaos code...
>
> I followed up on LADSPA (http://www.ladspa.org/). Rather
> like OSC, it looks like a vague low-level protocol that
> doesn't go as far as specifying pitch. But I checked out
> the example code and all the synthesizers take a frequency
> input. So, if anybody writes a microtonal-aware LADSPA host
> it'll be able to embed any plug-in that follows this convention.
>
> The bad news is that the suggested higher-level protocol for
> synthesizers, DSSI (http://dssi.sourceforge.net/) does seem
> to imply a 128 note limit. Again, nothing about pitch is
> specified, but the specification is obviously incomplete so,
> again, I looked at the example code. The trivial_synth.c
> still uses a LADSPA framework with a frequency control. But
> it's controlled by ALSA events which I tracked down here:
>
>
http://www.alsa-project.org/alsa-doc/alsa-lib/structsnd__seq__ev__note.html
>
> There's an unsigned char for "note" which of course means
> you can never get more than 256 notes and I'm sure most
> plugins will ignore everything beyond 128. There's also no
> "frequency" element so you have to specify tuning tables
> separately to the note-on, as with MIDI.
>
> I don't know how settled this is, who we should complain to,
> or if it really matters. But for microtonal purposes a
> frequency in Hz is a much better control value than a note
> number. The note to frequency conversion should be handled
> in a MIDI abstraction layer, not in each synthesizer plugin.
> I hope we can agree on that.
>
>
> Graham
>

Aaron Krister Johnson wrote:
> Graham,
> > Yes, unfortunately it seems that the convention of most softsynths is
> being followed by the LADSPA and DSSI plugins.

LADSPA itself looks fine, which is to be expected because they considered Csound when they designed it. Csound has never been restricted to a piano keyboard but still works fine with MIDI. If synth plugins were written with a Csound-like interface that didn't require Csound to run that'd be ideal for us. If you have contrary experience with LADSPA in the real world that's too bad.

The problem with DSSI seems to be that they fell in the MIDI trap. It means the tuning has to be implemented in the plugin, and so we need to lobby each softsynth developer to get them to support tuning tables.

> I would however be willing to bet that if you forwarded your comments
> to the developers they might be considered in future releases. but who
> knows for sure....it's worth a try, anyway. Maybe at the very least, a
> fork could be developed.

No harm in trying! The larger community I speak for the better. It looks like they're too far down the line to break backwards compatibility with existing synths. But perhaps a standard wrapper to make a more general synth fit the existing model would do the trick. Then we could apply a different wrapper for a different model and ignore plugins that do it the current way.

It isn't only microtonalists this affects. It's a pain for modelling violins and all kinds of other instruments as well. Exactly the things a post-MIDI protocol should be fixing.

An alternative note-on message with a frequency parameter would work as well. But the problem is that the simplest thing will be to ignore it and that's what programmers will do. It should be easier to not worry about tuning at all.

Graham

Graham Breed wrote:

> It isn't only microtonalists this affects. It's a pain for > modelling violins and all kinds of other instruments as > well. Exactly the things a post-MIDI protocol should be fixing.

For modeling things like a violin, it would be useful to have a whole set of continuous parameters for things like bow pressure, speed, and distance from the bridge. You'd need to deal with notes that start on one pitch and slide up or down at the end (for an expressive effect), and to have control over both rate and depth of vibrato. So I wonder if it would make sense to have pitch as just another continuous parameter like the rest. One difference is that the resolution for pitch would have to be higher than for other parameters. But you could say that there are really only four "notes" on a violin (one for each string) and use the pitch parameter to select any arbitrary pitch on the string (within the range of pitches that are usable on that string).

(Another thing about the violin that MIDI doesn't handle is the difference between whether or not the bow remains on the string after the end of the note. Although I guess that could be handled like the sustain pedal on a piano. Bow direction could be handled by using a signed value for bow speed.)

Aaron Krister Johnson wrote:
> Graham,
> > Yes, unfortunately it seems that the convention of most softsynths is
> being followed by the LADSPA and DSSI plugins.

No comments overnight I see. Does anybody care?

I've done some more poking and discovered GMPI. DSSI is only a stop-gap until we all start using GMPI (rather like Linux and HURD). GMPI is being sponsored by the MIDI Manufacturers Association and they seem to have nearly finished and then stopped.

The nitty gritty is at links like this:

http://www.gmpi-plugins.org/gmpi/requirements.php

which I can't reach. But I found this old mailing list post, which is promising:

http://www.freelists.org/archives/gmpi/02-2003/msg00016.html

"""
- Abstract note support
- Note identification not based on pitch.
- Not restricted to MIDI limitations (microtonal pitches
for example)
- Full customizable set of parameters per note
- Note tracking after Note Off event.
"""

That looks like what we want. It isn't interesting enough that I could find any more discussion of it, though.

> I would however be willing to bet that if you forwarded your comments
> to the developers they might be considered in future releases. but who
> knows for sure....it's worth a try, anyway. Maybe at the very least, a

If somebody could send a list of VST plugins that support tuning tables that might help. Getting the protocol right would greatly help with implementing such plugins. If we don't have clout as users the fact that VST authors are dealing with these issues is surely significant.

My prosed solution is:

URGENT

- add a floating point pitch specification to the note-on message (either specifying frequency in Hz or a fractional MIDI note number, whatever plugin developers feel they'd rather work with).

- make the DSSI API set this pitch to be 12= A440 where the host doesn't supply it

- encourage pitched-instrument plugins to use this pitch value, instead of calculating it themselves

DESIRED

- allow hosts to specify the pitch of a note-on independently of the MIDI note number (which can still be used for unpitched instruments and channel stealing algorithms)

- add tuning table support to the DSSI layer (or maybe allow for plugins to handle this somehow)

- encourage MIDI interfaces to do the right thing with MIDI Tuning Specification messages

I think this will maintain backwards compatibility, but make it easy for plugins to be microtuneable.

The mailing list, if anybody wants to start complaining, is:

http://sourceforge.net/mail/?group_id=104230

As I don't use VST or LADSPA I'm not an obvious potential user, although I do use Csound in a way that won't be compatible with what they have now as I understand it.

Graham

Herman Miller wrote:
> Graham Breed wrote:
> > >>It isn't only microtonalists this affects. It's a pain for >>modelling violins and all kinds of other instruments as >>well. Exactly the things a post-MIDI protocol should be fixing.
> > For modeling things like a violin, it would be useful to have a whole > set of continuous parameters for things like bow pressure, speed, and > distance from the bridge. You'd need to deal with notes that start on > one pitch and slide up or down at the end (for an expressive effect), > and to have control over both rate and depth of vibrato. So I wonder if > it would make sense to have pitch as just another continuous parameter > like the rest. One difference is that the resolution for pitch would > have to be higher than for other parameters. But you could say that > there are really only four "notes" on a violin (one for each string) and > use the pitch parameter to select any arbitrary pitch on the string > (within the range of pitches that are usable on that string).

LADSPA uses 32-bit floats for all parameters. And it should also be capable of handling a model like this. I'm not sure if DSSI allows parameters to affect individual notes so you might have to make it one string per channel (which would also fit MIDI better). Still, if violin models did use DSSI they'd probably find a work-around so we don't need to bother the specification team. Although a standard "frequency" parameter would be nice.

> (Another thing about the violin that MIDI doesn't handle is the > difference between whether or not the bow remains on the string after > the end of the note. Although I guess that could be handled like the > sustain pedal on a piano. Bow direction could be handled by using a > signed value for bow speed.)

There's always a work-around!

Graham