27 Sep
2008
27 Sep
'08
6:55 a.m.
Hi,
I have turned an old analogue electric organ into a MIDI controller. All the
old push buttons, switches, pots, drawbars can now trigger MIDI events.
Because I would like to make the MIDI messages static (i.e. they are linked
with particular buttons and faders and will not be changed) I have thought of
using an external application (keykit in this case) to work on incoming MIDI
events of the MIDI controller, filter them and trigger newly defined MIDI
events with it.
I would like to make the MIDI messages transmitted by the controller as short
as possible. I have thought of assigning the Bx (Control Change) command to
the buttons and faders, but this would mix with/overwrite other control
change commands sent by other MIDI devices.
It has to be possible to distinguish between the buttons/faders by the MIDI
message that each one triggers.
How about the System Common Message F4 and F5 which are not yet defined in the
MIDI standard? Could I add some extra data bytes to identify the type (button
or fader), the number and value?
Like this:
F4 125 70 (Fader 125 sends value 70)
keykit would recognize this fader and set volume level for channel 2 for
fluidsynth.
Or, in another situation, increase sustain value for channel 3 for fluidsynth.
or:
F5 10 1 (Button 10 sends value ON)
keykit would recognize the button and turn on sustain for channel 1.
Thanks for any hint and kind regards,
Crypto.
27 Sep
27 Sep
8:02 a.m.
On Sat, Sep 27, 2008 at 12:55:52PM +0200, Crypto wrote:
Because I would like to make the MIDI messages static
(i.e. they are linked
with particular buttons and faders and will not be changed) I have thought of
using an external application (keykit in this case) to work on incoming MIDI
events of the MIDI controller, filter them and trigger newly defined MIDI
events with it.
Have a look at MIDIDINGS:
<http://das.nasophon.de/mididings>
Very flexible and easy to program.
I would like to make the MIDI messages transmitted by
the controller as short
as possible. I have thought of assigning the Bx (Control Change) command to
the buttons and faders, but this would mix with/overwrite other control
change commands sent by other MIDI devices.
Not if you use a separate channel. Or a separate interface.
How about the System Common Message F4 and F5 which
are not yet defined in the
MIDI standard? Could I add some extra data bytes to identify the type (button
or fader), the number and value?
Don't. It's not even defined how many bytes should follow
these codes. And they are _system_ commands.
If you can't use controllers, use sysex. The overhead is not
that much.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Wie der Mond heute Nacht aussieht !
Ist es nicht ein seltsames Bild ?
9:33 a.m.
That sounds like a nice project. What kind of organ was it and what did you use as the
MIDI controller?
You could use SYSEX for these kind of messages however SYSEX is a bit painful with regards
to having a recognised SYSEX ID - officially you should request one from the MIDI
Manufacturers association which can be a bit of a pain in the butt if you are working on a
free, open source application since you have to pay for this 'pleasure'. If you do
choose to use SYSEX then you keyboard will probably only ever interoperate with your own
interpreter since nothing else would respond to you SYSEX. That may be what you want
however to use it as a general controller then you probably don't want this
restriction.
You may want to look into using NRP controls but that does have gory stuff attached to it:
firstly you would have to select the Non Registered Parameter you want to change then give
the data values you want to set it to. Changing from one controller to another does
require extra messaging however once you have selected a control you are left with just
data entry. The data entry can be 7 or 14 bit and you actually leave it up to other end to
decide how to handle - it puts a bit more onus on your interpreter code to recognise when
you have a 7 or 14 bit value. The actual amount of data you need to send may also be quite
large but if the only reciever is going to be your interpreter then you will have
flexibilty in the translations from NRP to whatever paramter you want to send onwards.
Perhaps you actually just want to have a look at what you want these controls to do.
Depending on how many you have and what you want to control then you might find the GM
default MIDI mappings are all you need, giving you things like ADRS parameters, filter
parameters, FX parameters, etc. The truth is that the GM spec is a bit restrictive but
that depends on what you want to achieve. Also, if you get GM to work and the code is well
written then you can extend it from there to drive different synths with non-GM mappings.
Regards,
NIck.
Date: Sat, 27 Sep 2008 13:58:36 +0200
From: fons(a)kokkinizita.net
To: linux-audio-user(a)lists.linuxaudio.org
Subject: Re: [LAU] Usage of undefinded MIDI mesages
On Sat, Sep 27, 2008 at 12:55:52PM +0200, Crypto wrote:
_________________________________________________________________
Invite your mail contacts to join your friends list with Windows Live Spaces. It's
easy!
http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.…
Because I would like to make the MIDI messages
static (i.e. they are linked
with particular buttons and faders and will not be changed) I have thought of
using an external application (keykit in this case) to work on incoming MIDI
events of the MIDI controller, filter them and trigger newly defined MIDI
events with it.
Have a look at MIDIDINGS:
<http://das.nasophon.de/mididings>
Very flexible and easy to program.
I would like to make the MIDI messages
transmitted by the controller as short
as possible. I have thought of assigning the Bx (Control Change) command to
the buttons and faders, but this would mix with/overwrite other control
change commands sent by other MIDI devices.
Not if you use a separate channel. Or a separate interface.
How about the System Common Message F4 and F5
which are not yet defined in the
MIDI standard? Could I add some extra data bytes to identify the type (button
or fader), the number and value?
Don't. It's not even defined how many bytes should follow
these codes. And they are _system_ commands.
If you can't use controllers, use sysex. The overhead is not
that much.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Wie der Mond heute Nacht aussieht !
Ist es nicht ein seltsames Bild ?
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
2:22 p.m.
Nick,
it is a Dr. Boehm CnT/L. These organs were sold as a kit until about 1982.
This one was made in 1978.
I have stripped out all of the old analogue circuitry while keeping the
drawbars, push buttons and turning knobs, and using the circuit boards of a
MIDIbox64 project I built my own MIDI controller.
The two manuals and pedal were already converted to digital via a genuine
Boehm MIDI controller, but the drawbars, pushbuttons etc. were not.
I have finished the hardware part of the controller, now I am busy getting the
programming to work.
There are several things that make the whole business rather complicated:
I am planning to mimic the behaviour of the old single finger chord drum
accompaniment and recreate the rhythm section. And I want to switch between
GM compatible SF2 sounds and B4II organ. All of these have their own features
that have to be made to work with the drawbars and switches. And there is an
LED panel as well, that should display the function of the buttons and
drawbars when operated or give other useful hints.
I have finished programming the MIDI box64 controller part although at the
moment it does not much apart from sending a SYSTEM EXCLUSIVE message when
pulling drawbars / pressing switches, and I want to use keykit for tracking
these messages and converting them into MIDI messages for the applications
that I use. I think that using an external "host" application for preparing
all of the MIDI stuff is easier to use because it offers more memory and is
quicker to program. There is more to come as soon as I have things working
together as expected (more "convenience functions").
I have used the SYS EX command now with an "arbitrary" ID that I hope no other
component (hardware, software) is recognizing apart from keykit - but only
because I will tell keykit to recognize it...
It seems to me that NRP controller will produce too much overhead for simply
switching a sound on and off. I know that normally a PRESET CHANGE would do
that, but such a command cannot toggle sounds, like stops of a church organ,
but only switch between them.
Regards,
Crypto.
Am Saturday 27 September 2008 15:33:25 schrieb Nick Copeland:
That sounds like a nice project. What kind of organ
was it and what did you
use as the MIDI controller?
You could use SYSEX for these kind of messages however SYSEX is a bit
painful with regards to having a recognised SYSEX ID - officially you
should request one from the MIDI Manufacturers association which can be a
bit of a pain in the butt if you are working on a free, open source
application since you have to pay for this 'pleasure'. If you do choose to
use SYSEX then you keyboard will probably only ever interoperate with your
own interpreter since nothing else would respond to you SYSEX. That may be
what you want however to use it as a general controller then you probably
don't want this restriction.
You may want to look into using NRP controls but that does have gory stuff
attached to it: firstly you would have to select the Non Registered
Parameter you want to change then give the data values you want to set it
to. Changing from one controller to another does require extra messaging
however once you have selected a control you are left with just data entry.
The data entry can be 7 or 14 bit and you actually leave it up to other end
to decide how to handle - it puts a bit more onus on your interpreter code
to recognise when you have a 7 or 14 bit value. The actual amount of data
you need to send may also be quite large but if the only reciever is going
to be your interpreter then you will have flexibilty in the translations
from NRP to whatever paramter you want to send onwards.
Perhaps you actually just want to have a look at what you want these
controls to do. Depending on how many you have and what you want to control
then you might find the GM default MIDI mappings are all you need, giving
you things like ADRS parameters, filter parameters, FX parameters, etc. The
truth is that the GM spec is a bit restrictive but that depends on what you
want to achieve. Also, if you get GM to work and the code is well written
then you can extend it from there to drive different synths with non-GM
mappings.
Regards,
NIck.
3:55 p.m.
On Sat, 27 Sep 2008 20:22:53 +0200
Crypto <crypto(a)online.de> wrote:
Nick,
it is a Dr. Boehm CnT/L. These organs were sold as a kit until about 1982.
This one was made in 1978.
I have stripped out all of the old analogue circuitry while keeping the
drawbars, push buttons and turning knobs, and using the circuit boards of a
MIDIbox64 project I built my own MIDI controller.
The two manuals and pedal were already converted to digital via a genuine
Boehm MIDI controller, but the drawbars, pushbuttons etc. were not.
I have finished the hardware part of the controller, now I am busy getting the
programming to work.
There are several things that make the whole business rather complicated:
I am planning to mimic the behaviour of the old single finger chord drum
accompaniment and recreate the rhythm section. And I want to switch between
GM compatible SF2 sounds and B4II organ. All of these have their own features
that have to be made to work with the drawbars and switches. And there is an
LED panel as well, that should display the function of the buttons and
drawbars when operated or give other useful hints.
I have finished programming the MIDI box64 controller part although at the
moment it does not much apart from sending a SYSTEM EXCLUSIVE message when
pulling drawbars / pressing switches, and I want to use keykit for tracking
these messages and converting them into MIDI messages for the applications
that I use. I think that using an external "host" application for preparing
all of the MIDI stuff is easier to use because it offers more memory and is
quicker to program. There is more to come as soon as I have things working
together as expected (more "convenience functions").
I have used the SYS EX command now with an "arbitrary" ID that I hope no other
component (hardware, software) is recognizing apart from keykit - but only
because I will tell keykit to recognize it...
It seems to me that NRP controller will produce too much overhead for simply
switching a sound on and off. I know that normally a PRESET CHANGE would do
that, but such a command cannot toggle sounds, like stops of a church organ,
but only switch between them.
Regards,
Crypto.
That's quite a challenge you've set yourself :o
Please keep us informed on how you get on.
--
Will J Godfrey
http://www.musically.me.uk
4:58 p.m.
Hiho,
On Saturday 27 September 2008 06:55:52 Crypto wrote:
I have turned an old analogue electric organ into a
MIDI controller. All
the old push buttons, switches, pots, drawbars can now trigger MIDI events.
Because I would like to make the MIDI messages static (i.e. they are linked
with particular buttons and faders and will not be changed) I have thought
of using an external application (keykit in this case) to work on incoming
MIDI events of the MIDI controller, filter them and trigger newly defined
MIDI events with it.
I would like to make the MIDI messages transmitted by the controller as
short as possible. I have thought of assigning the Bx (Control Change)
command to the buttons and faders, but this would mix with/overwrite other
control change commands sent by other MIDI devices.
It has to be possible to distinguish between the buttons/faders by the MIDI
message that each one triggers.
I think it is most common use to use CC for this. Any CV-to-MIDI box does
this, as far as I know.
The higher CC messages do not have a fixed meaning in the MIDI specification,
so they are open to interpretation.
so the messages would be CC - cc no - cc value
Channels are used to distinguish between different MIDI devices, so that is
how you are supposed to do it too. Make it configurable on your box with some
DIP-switches maybe.
If you do it like this, you can also use your MIDI controller to control
something like a Nord Modular, where you can assign Midi CC to (virtual)
knobs in your synthesizer patches. And you won't even have to bring your
computer to a gig then...
sincerely,
Marije
1 Oct
1 Oct
4:09 p.m.
Hi,
as there seemed to be some interest in how I get on with my project:
I have made at least some progress concerning the conversion of my analogue
organ. Finally, I have found a way to switch sounds like stops.
There are now up to 20 different sounds playing on channel #1, 8 different
sounds for channels #2 and #3. I can press the old switch buttons of the
organ which I have converted to digital and I get the sounds switched on and
off.
Some big problems that yet have to be solved:
That many different sounds playing at the same time is too much. I haven't yet
tried all alternatives and finetuned the RT settings etc., but the sound is
stuttering and crackling rather quickly, when I have set all 20 sounds to
play on channel #1.
I know it is rather unlikely that all 20 switches (stops) are pulled at the
same time. I have of course done anyway as a test.
I think I need some kind of "NO SOUND" preset, that does not consume any or
nearly no processing power? At the moment I had to switch to the sounds I
want (= a pulled stop; sound is ON) or switch to another sound as a "neutral"
sound. Just to hear the difference of it, if is it working at all.
How did I do it?
First, I run a CLI script that runs fluidsynth with 48 virtual MIDI channels
via a named pipe and then runs keykit.
Then I run a keykit function. This sends system messages to the system
commandline and from there to fluidsynth via the named pipe. The function
reacts upon incoming MIDI events and when it finds a special SYS EX message I
have created for each switch it turns the sounds on and off.
To get several sounds to play at the same time on the same channel I have
programmed lots of router commands. Channel #1 alone is routed to 20 virtual
channels which are all active at the same time. This is where the problem
arises that I get crackled sound: After the router rules have been set up all
of the virtual channels need a preset to play. There seems to be no way
to "mute" or de-activate a particular router roule. One can only delete all
of them or add a single one to the router rule "chain". I have created 36
router rules.
If You have got a nice hint about how to create a "no sound" preset, mute a
channel alltogether (simply setting volume to 0 will not be sufficient) and
the crackled sound problem, then I'm looking forward to reading about it
here.
Regards,
Crypto.
Am Saturday 27 September 2008 12:55:52 schrieb Crypto:
Hi,
I have turned an old analogue electric organ into a MIDI controller. All
the old push buttons, switches, pots, drawbars can now trigger MIDI events.
Because I would like to make the MIDI messages static (i.e. they are linked
with particular buttons and faders and will not be changed) I have thought
of using an external application (keykit in this case) to work on incoming
MIDI events of the MIDI controller, filter them and trigger newly defined
MIDI events with it.
I would like to make the MIDI messages transmitted by the controller as
short as possible. I have thought of assigning the Bx (Control Change)
command to the buttons and faders, but this would mix with/overwrite other
control change commands sent by other MIDI devices.
It has to be possible to distinguish between the buttons/faders by the MIDI
message that each one triggers.
How about the System Common Message F4 and F5 which are not yet defined in
the MIDI standard? Could I add some extra data bytes to identify the type
(button or fader), the number and value?
Like this:
F4 125 70 (Fader 125 sends value 70)
keykit would recognize this fader and set volume level for channel 2 for
fluidsynth.
Or, in another situation, increase sustain value for channel 3 for
fluidsynth.
or:
F5 10 1 (Button 10 sends value ON)
keykit would recognize the button and turn on sustain for channel 1.
Thanks for any hint and kind regards,
Crypto.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
5691
days inactive
5695
days old
linux-audio-user@lists.linuxaudio.org
6 comments
5 participants
participants (5)
-
Crypto -
Folderol -
Fons Adriaensen -
nescivi -
Nick Copeland