5 Oct
2009
5 Oct
'09
6:47 p.m.
Completely agree that SYSEX is where this kind of functionality should reside.
This use of 0x7d is a bit antiquated, no? The reassignment of 0x00 to indicate 3 byte
SYSEX ID means there is a bit more flexibility in the system. Currently the following
are assigned:
0x00 0x00 0xXX American group
0x00 0x01 0xXX American group
0x00 0x20 0xXX European group
0x4X Japanese group (with holes)
0x5X Japanese group (with holes)
0x00 0x04 Japanese group
Getting a registration requires it be paid for, pretty ludicrous for what purports to be
an open standard. I would suggest that Open Source developers should simply take
one of the unassigned values for its own first digit, agree between themselves who
get the next two digits for their apps and SYSEX then be sent with 3 byte ID.
SLab hijacked 0x53 about 10 years ago for this purpose and bolted on a three more
digits for personal identification and there is little reason why this should not be done
again, this time in line with the current MMA SYSEX ID defs as above? If open source
goes and squats on 0x7d then everybody can go and haggle over which app gets the
next two digits.
There is probably going to be some complaints that SYSEX require an extra two
bytes and how that is going to degrade system performance at 31.25KHz, which
probably needs a pre-canned response as it is a non-issue.
This discussion is perhaps better aimed at LAD rather than LAU: LAU justs wants it
to work, LAD can horsetrade on the details.
It is possible that the MMA will take an issue with this since it does not actually fit
within the new SYSEX ID specs (0x7d has not been assigned in the new definition)
but I am pretty sure that if open source applications restrict themselves to their own
set of second and third digits then the MMA will not be so daft as to assign that
number to any manufacturer. For the apps that eventually go commercial then
it is their job, as a part of the commercialisation, to formally request their own ID
from MMA and then to recognise both of them if desired - the MMA assigned one
thanks to paying $$$ for the number, and the squatted ID for compatibility purposes.
Now, to tie this back into the original subject: this does not really help with assigning
MIDI controllers back to app controls as now the surface has to be configured to
generate more complex SYSEX messages, neither easy nor even possible with some of
them, but the argument of applications getting screwed by using the same number
is actually very easy to avoid, admittedly as long as it is done unanimously. Perhaps
linuxaudio.org might want to pick up the gauntlet of assigning the open sourced
digits?
Regards, nick
"we have to make sure the old choice [Windows] doesn't disappear”.
Jim Wong, president of IT products, Acer
Date: Mon, 5 Oct 2009 19:19:17 +0200
From: fons(a)kokkinizita.net
To: linux-audio-user(a)lists.linuxaudio.org
Subject: Re: [LAU] So what's the deal with controlling the aeolus organ?stops via
midi
On Mon, Oct 05, 2009 at 07:00:40PM +0200, Pedro Lopez-Cabanillas wrote:
"we have to make sure the old choice [Windows] doesn't disappear”.
Jim Wong, president of IT products, Acer
The MMA requires that you use a registered
manufacturer ID, but only for
commercial products. There is a special ID = 0x7D that is intended for
educational or development use only, and should never appear in a commercial
design.
Where it is silently assumed that 'educational' and 'development'
implies 'not distributed', or at least 'never used together with
any other app using the same ID'.
If two or more open source programs use 0x7D and they happen to
see the same MIDI stream then one of them will be screwed.
Ciao,
--
FA Date: Mon, 5 Oct 2009 19:19:17 +0200
From: fons(a)kokkinizita.net
To: linux-audio-user(a)lists.linuxaudio.org
Subject: Re: [LAU] So what's the deal with controlling the aeolus organ?stops via
midi
On Mon, Oct 05, 2009 at 07:00:40PM +0200, Pedro Lopez-Cabanillas wrote:
>
> Io lo dico sempre: l'Italia è troppo stretta e lunga.
>
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user(a)lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
_________________________________________________________________
Windows Live: Make it easier for your friends to see what you’re up to on Facebook.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/so…
The MMA requires that you use a registered
manufacturer ID, but only for
commercial products. There is a special ID = 0x7D that is intended for
educational or development use only, and should never appear in a commercial
design.
Where it is silently assumed that 'educational' and 'development'
implies 'not distributed', or at least 'never used together with
any other app using the same ID'.
If two or more open source programs use 0x7D and they happen to
see the same MIDI stream then one of them will be screwed.
Ciao,
--
FA 
6 Oct
6 Oct
12:37 a.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
On Mon, 2009-10-05 at 22:47 +0200, Nick Copeland wrote:
Completely agree that SYSEX is where this kind of
functionality should
reside.
Using SYSEX more or less completely screws you for sequencing things
easily/nicely, among a zillion other irritating compatibility issues.
Not enough context quoted to tell; are the stops in Aeolus really too
complicated to be controlled via controllers and programs? SYSEX should
only be used where it is literally impossible to achieve something
without it.
-dr
3:47 a.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
David Robillard wrote:
Not enough context quoted to tell; are the stops in
Aeolus really too
complicated to be controlled via controllers and programs?
No: For 55 or so organ stops, you'd need 55 boolean controllers; this
can be easily done with NRPNs.
Best regards,
Clemens
9:05 a.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
On Tue, Oct 6, 2009 at 1:47 AM, Clemens Ladisch <clemens(a)ladisch.de> wrote:
David Robillard wrote:
they don't even need to be NRPNs. there's nothing requiring the
interpretation of MIDI CC #7 as "volume" unless it makes sense for the
application. etc.
Not enough context quoted to tell; are the stops
in Aeolus really too
complicated to be controlled via controllers and programs?
No: For 55 or so organ stops, you'd need 55 boolean controllers; this
can be easily done with NRPNs. 
11:08 a.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
Paul Davis wrote:
On Tue, Oct 6, 2009 at 1:47 AM, Clemens Ladisch
<clemens(a)ladisch.de> wrote:
Keep in mind that you might want to control 2 devices in unison. You
will send control 7 to both devices, one device is using it for volume
and the other device is using it for anything else. It's not a good idea
to use control 7, because for some oldish synth you can't disable
receiving control 7.
David Robillard wrote:
they don't even need to be NRPNs. there's nothing requiring the
interpretation of MIDI CC #7 as "volume" unless it makes sense for the
application. etc. Not enough context quoted to tell; are the stops
in Aeolus really too
complicated to be controlled via controllers and programs?
No: For 55 or so organ stops, you'd need 55 boolean controllers; this
can be easily done with NRPNs.
12:12 p.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
On Tue, Oct 6, 2009 at 9:08 AM, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote:
Keep in mind that you might want to control 2 devices
in unison. You will
send control 7 to both devices, one device is using it for volume and the
other device is using it for anything else. It's not a good idea to use
control 7, because for some oldish synth you can't disable receiving control
7.
that's why MIDI has 16 channels.
1:36 p.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
Paul Davis wrote:
On Tue, Oct 6, 2009 at 9:08 AM, Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net> wrote:
That doesn't help you when you'er playing one synth by it's keyboard and
another synth in unison by MIDI, while both synth don't support
disabling some MIDI controllers. That's why it's common not to use
control 7 for anything else but volume.
Keep in mind that you might want to control 2
devices in unison. You will
send control 7 to both devices, one device is using it for volume and the
other device is using it for anything else. It's not a good idea to use
control 7, because for some oldish synth you can't disable receiving control
7.
that's why MIDI has 16 channels.
1:30 p.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
The issue with using the predefined CC such as #7 for other uses is that if any GM
controller sits on your MIDI channel it will use that as a volume control, and it will be
reinterpreted by Aeolus as some organ setting. The result is highly unpredictable and I
don't think there are 55 unassigned CC available.
The same is actually true of NRP: as the NRP has no concept of source or dest other than
the MIDI channel then if you want to control two devices over the same channel
(multilayered/multitimbral gives nice results with a bit if detune) then the NRP are also
going to collide. Bristol did just this in 0.10 and then backed down after a few
complaints of lost output or wild signals to the point where it was unusable, people were
downgrading to 0.9 - the use of NRP in bristol were proposed as an alternative to the
squatted SYSEX message which have always worked as they never collided with anything (but
themselves). The option to honour NRP is still there, just not default and I would have
backed it out completely except it was easy to leave under flag control.
Having everything after 0xf0 as reassignable is a pretty cool idea. SYSEX message can
collide too unless the message format includes a further system identifier such as
bristols negotiation handles but they only work over TCP. I think I might put that on the
wishlist.
Out of interest, what was the problem with MIDI sequencing and SYSEX? The only problem I
knew about was that they are atomic and cannot be interupted hence on 'legacy'
5-pin DIN at a meagre few kilobaud there were timing issues, largely overcome now with USB
unless you want to download gigasamples.
Regards, nick.
"we have to make sure the old choice [Windows] doesn't disappear”.
Jim Wong, president of IT products, Acer
Date: Tue, 6 Oct 2009 07:47:27 +0200
From: clemens(a)ladisch.de
CC: linux-audio-user(a)lists.linuxaudio.org; linux-audio-dev(a)lists.linuxaudio.org
Subject: Re: [LAD] [LAU] So what's the deal with controlling the aeolus organ?stops
via midi
David Robillard wrote:
_________________________________________________________________
Windows Live: Keep your friends up to date with what you do online.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/so…
Not enough context quoted to tell; are the stops
in Aeolus really too
complicated to be controlled via controllers and programs?
No: For 55 or so organ stops, you'd need 55 boolean controllers; this
can be easily done with NRPNs.
Best regards,
Clemens
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
1:55 p.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
Nick Copeland wrote:
Having everything after 0xf0 as reassignable is a pretty cool idea.
Maybe often used manufacture IDs, eg. Roland, Yamaha, should be excluded ;).
Out of interest, what was the problem with MIDI
sequencing and SYSEX?
The only problem I knew about was that they are atomic and cannot be
interupted hence on 'legacy' 5-pin DIN at a meagre few kilobaud there
were timing issues, largely overcome now with USB unless you want to
download gigasamples.
Using one output just for a synth that receives SysEx on real-time e.g.
to control it's filters isn't a problem for standard MIDInterfaces too,
but there's another issue. Not all Sequencers have an option to edit
SysEx. If your device can't send e.g. SysEx for filters, but only
receive such data, you're not able to use this functions. Nearly every
sequencer is able to transform controllers, e.g. you sent 1 (modulation
wheel) and transform it to 6 (Data Byte) for the receiving device.
2:58 p.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
On Tue, Oct 6, 2009 at 11:30 AM, Nick Copeland
<nickycopeland(a)hotmail.com> wrote:
Out of interest, what was the problem with MIDI
sequencing and SYSEX? The
only problem I knew about was that they are atomic and cannot be interupted
hence on 'legacy' 5-pin DIN at a meagre few kilobaud there were timing
issues, largely overcome now with USB unless you want to download
gigasamples.
how do you edit the messages? it requires "librarian" style
application handling.
3:13 p.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
Paul Davis wrote:
how do you edit the messages? it requires
"librarian" style
application handling.
As mentioned before I do agree with you Paul, but anyway there are
sequencers like the Atari Cubase that makes it possible that even
absolutely noobs can edit a GUI to edit SysEx by the sequencer. For
Linux and this app we are talking about it might work this way: The app
is sending the data, the sequencer records the data and there's no need
to edit SysEx by the user. Anyway, some might like to use some
controllers when playing his keyboard. It would be smart to have an
option, that a chosen parameter would be able to receive just control 6
without NRPN, while the other parameters only could be controlled by SysEx.
3:15 p.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
On Tue, Oct 6, 2009 at 1:13 PM, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote:
Paul Davis wrote:
you've missed my point.
if aeolus is currently programmed to switch to stop setting S1, and i
want it to switch setting S2 instead, what do i, as a user do? what do
i have to know?
how do you edit the messages? it requires "librarian" style
application handling.
As mentioned before I do agree with you Paul, but anyway there are
sequencers like the Atari Cubase that makes it possible that even absolutely
noobs can edit a GUI to edit SysEx by the sequencer.
3:26 p.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
Does any know if hidef MIDI will address these issues? The MMA is not very transparent
regarding what they want to put in there.
Regards, nick.
"we have to make sure the old choice [Windows] doesn't disappear”.
Jim Wong, president of IT products, Acer
Date: Tue, 6 Oct 2009 13:15:31 -0400
Subject: Re: [LAD] [LAU] So what's the deal with controlling the aeolus organ?stops
via midi
From: paul(a)linuxaudiosystems.com
To: ralf.mardorf(a)alice-dsl.net
CC: nickycopeland(a)hotmail.com; clemens(a)ladisch.de; linux-audio-dev(a)lists.linuxaudio.org
On Tue, Oct 6, 2009 at 1:13 PM, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote:
_________________________________________________________________
Windows Live: Make it easier for your friends to see what you’re up to on Facebook.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/so…
Paul Davis wrote:
you've missed my point.
if aeolus is currently programmed to switch to stop setting S1, and i
want it to switch setting S2 instead, what do i, as a user do? what do
i have to know?
how do you edit the messages? it requires "librarian" style
application handling.
As mentioned before I do agree with you Paul, but anyway there are
sequencers like the Atari Cubase that makes it possible that even absolutely
noobs can edit a GUI to edit SysEx by the sequencer.
3:31 p.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
Nick Copeland wrote:
Does any know if hidef MIDI will address these issues?
The MMA is not
very transparent
regarding what they want to put in there.
Some days ago I visited the MMA site and didn't found anything about
hidef MIDI, today I found this, but didn't read it:
http://www.midi.org/news/hd.php
Resp. I did read the last sentence: "Companies that are interested in
participating in the development of the new HD Protocol should contact
the MMA (see the contact form <http://www.midi.org/aboutus/contact.php>
on this site.)"
3:26 p.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
Paul Davis wrote:
you've missed my point.
if aeolus is currently programmed to switch to stop setting S1, and i
want it to switch setting S2 instead, what do i, as a user do? what do
i have to know?
I don't know Aeolus, but usually a user should be able to change between
setting 1 and setting 2 by the GUI of the application, just by using the
mouse and without any knowledge about 0xf0 and 0xf7. The SysEx data
should be sent by MIDI, while the user just switch from setting 1 to
setting 2 by the GUI and a sequencer could receive it.
A misunderstanding because we are writing on English? It's not my native
language ;).
3:37 p.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
On Tue, Oct 6, 2009 at 1:26 PM, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote:
Paul Davis wrote:
so you are saying that in order to edit a sequence that contains
requests for stop changes, the user must understand the *internal*
structure of a sysex message? and this is even more true when they go
to create the first such request (rather than edit an existing one) ?
you've missed my point.
if aeolus is currently programmed to switch to stop setting S1, and i
want it to switch setting S2 instead, what do i, as a user do? what do
i have to know?
I don't know Aeolus, but usually a user should be able to change between
setting 1 and setting 2 by the GUI of the application, just by using the
mouse and without any knowledge about 0xf0 and 0xf7. The SysEx data should
be sent by MIDI, while the user just switch from setting 1 to setting 2 by
the GUI and a sequencer could receive it.
4:08 p.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
so you are saying that in order to edit a sequence
that contains
requests for stop changes, the user must understand the *internal*
structure of a sysex message? and this is even more true when they go
to create the first such request (rather than edit an existing one) ?
This depends to the sequencer. IIRC for Cubase's Atari version, at least
the real version (the free one for usage with Atari emulators seems to
be completely different), works this way:
The user needs to copy out the hex numbers for a wanted function from
the user manual and set a variable for the data that should be changed
and by mouse he can assign a fader to this code and tell the fader how
many steps he should do, the checksum is determined automatically. By
this function I had an real-time editor for Cubase to edit the MT-32 and
Matrix Oberheim-1000.
By the way handling SysEx isn't as hard to do as setting up a Linux
workstation ;). When I got my 1. Computer, a C64, I needed less then one
month from first usage of a computer to write my first MIDI SysEx
application in Assembler. I'm using Linux since years, but wasn't able
to set up 1 stable workstation for my home studio in this long time ;).
I won't belief that somebody who is able to make music by using Linux,
won't be able to handle SysEx data ;). Maybe he needs a short
introduction in hex numbers.
6:48 p.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
On Tue, Oct 06, 2009 at 07:26:18PM +0200, Ralf Mardorf wrote:
I don't know Aeolus, but usually a user should be
able to change between
setting 1 and setting 2 by the GUI of the application, just by using the
mouse and without any knowledge about 0xf0 and 0xf7. The SysEx data
should be sent by MIDI, while the user just switch from setting 1 to
setting 2 by the GUI and a sequencer could receive it.
A misunderstanding because we are writing on English? It's not my native
language ;).
A misunderstanding because you are apparently not aware of
how Aeolus is controlled. With the default instrument setup
there are around 55 'stops' wich can be switched ON or OFF
individually. In general Aeolus could have up to 256 of such
binary switches. Not all combinations make sense, but there
are still zillions of them that do. Such a system does not
map to anything standard in MIDI, but it is how a real pipe
organ is controlled.
Aeolus can store combinations of these switches as presets,
and you can then load these presets using the standard MIDI
bank/preset messages. But the discussion is about the format
of MIDI messages to control each switch individually.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
7:33 p.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
Fons Adriaensen wrote:
On Tue, Oct 06, 2009 at 07:26:18PM +0200, Ralf Mardorf
wrote:
For the default it would be very easy, 55 * on + 55 * off = 110
settings. An universal control change is number 6. This could be used to
sent by the data byte 110 different numbers ;), resp. 128.
0 = S1 off
1 = S1 on
2 = S2 off
3 = S2 on
etc.
Not a very smart solution, but easy to understand for green users, more
easy than using NRPN and controllers like 6, 96 and 97 are made for
similar issues.
I don't know Aeolus, but usually a user
should be able to change between
setting 1 and setting 2 by the GUI of the application, just by using the
mouse and without any knowledge about 0xf0 and 0xf7. The SysEx data
should be sent by MIDI, while the user just switch from setting 1 to
setting 2 by the GUI and a sequencer could receive it.
A misunderstanding because we are writing on English? It's not my native
language ;).
A misunderstanding because you are apparently not aware of
how Aeolus is controlled. With the default instrument setup
there are around 55 'stops' wich can be switched ON or OFF
individually. In general Aeolus could have up to 256 of such
binary switches. Not all combinations make sense, but there
are still zillions of them that do. Such a system does not
map to anything standard in MIDI, but it is how a real pipe
organ is controlled.
Aeolus can store combinations of these switches as presets,
and you can then load these presets using the standard MIDI
bank/preset messages. But the discussion is about the format
of MIDI messages to control each switch individually.
Ciao,
7:54 p.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
On Tue, Oct 06, 2009 at 11:33:13PM +0200, Ralf Mardorf wrote:
For the default it would be very easy, 55 * on + 55 *
off = 110 settings.
An universal control change is number 6. This could be used to sent by the
data byte 110 different numbers ;), resp. 128.
0 = S1 off
1 = S1 on
2 = S2 off
3 = S2 on
etc.
Not a very smart solution, but easy to understand for green users, more
easy than using NRPN and controllers like 6, 96 and 97 are made for similar
issues.
The default instrument has around 55 stops, but in
general it could have up to 8 groups of up to 32
stops each.
We need not only 'on' and 'off' but also 'toggle', and
commands to reset a group in a single operation.
Any protocol coded into Aeolus must be able to support
the maximum configuration, since such an instrument can
be created without recompiling the program.
The current format using controller 98 provides all of
this. It requires a maximum of two controller messages
per stop, and in most cases less.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
8:51 p.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
Fons Adriaensen wrote:
On Tue, Oct 06, 2009 at 11:33:13PM +0200, Ralf Mardorf
wrote:
Now I do understand :).
IMO SysEx is the best solution, even if there should be a way to solve
this by Controller Changes, because the user anyway would need a GUI to
keep track of editing Aeolus. There should be a GUI (an Aeolus editor)
able to send SysEx to Aeolus and to sequencers. The company's ID should
be selectable for Aeolus (and maybe an additional editor GUI) by some
exotic or unused MMA company's IDs.
I guess I really do understand why you're still searching for another
way and that there are some disadvantages by using SysEx, but it sounds
exactly like what SysEx is designed for, because the user needs a GUI to
control this settings and only some SysEx data must be changed
real-time, most of it could be done before making music.
It reminds me of synth from the 80ies without controls. After a while
there were not only software editors, but also hardware editors with
potentiometers and switches sending SysEx.
Ralf
For the default it would be very easy, 55 * on +
55 * off = 110 settings.
An universal control change is number 6. This could be used to sent by the
data byte 110 different numbers ;), resp. 128.
0 = S1 off
1 = S1 on
2 = S2 off
3 = S2 on
etc.
Not a very smart solution, but easy to understand for green users, more
easy than using NRPN and controllers like 6, 96 and 97 are made for similar
issues.
The default instrument has around 55 stops, but in
general it could have up to 8 groups of up to 32
stops each.
We need not only 'on' and 'off' but also 'toggle', and
commands to reset a group in a single operation.
Any protocol coded into Aeolus must be able to support
the maximum configuration, since such an instrument can
be created without recompiling the program.
The current format using controller 98 provides all of
this. It requires a maximum of two controller messages
per stop, and in most cases less.
Ciao,
7 Oct
7 Oct
7:19 a.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
On Wed, Oct 07, 2009 at 12:51:20AM +0200, Ralf Mardorf wrote:
I guess I really do understand why you're still
searching for another way
and that there are some disadvantages by using SysEx, but it sounds exactly
like what SysEx is designed for, because the user needs a GUI to control
this settings and only some SysEx data must be changed real-time, most of
it could be done before making music.
1. I'm not searching for another way. This thread started because
a user didn't understand the current way, and asked how to use it.
2. The user doesn't need a separate GUI - Aeolus already has one.
You setup the registration in Aeolus' GUI, save it as a preset
and when necessary reload that preset using standard MIDI command
generated by a sequencer. There can be 1024 presets, and this
number could be extended. But an organist would typically use
no more than say 20 stop combinations for a complete concert
(with rare exceptions).
3. The stop control protocol is not meant for sequencers. It was
added for users who build organ consoles and want to use 'real'
stop buttons on them.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
6 Oct
6 Oct
11:17 p.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
On Tue, 2009-10-06 at 22:45 +0200, Fons Adriaensen wrote:
On Tue, Oct 06, 2009 at 07:26:18PM +0200, Ralf Mardorf
wrote:
There's 16,384 NRPNs, easy fit. Bit high resolution/bloatey for binary
toggles, but a sysex solution would be just as bloatey anyway.
-dr
I don't know Aeolus, but usually a user
should be able to change between
setting 1 and setting 2 by the GUI of the application, just by using the
mouse and without any knowledge about 0xf0 and 0xf7. The SysEx data
should be sent by MIDI, while the user just switch from setting 1 to
setting 2 by the GUI and a sequencer could receive it.
A misunderstanding because we are writing on English? It's not my native
language ;).
A misunderstanding because you are apparently not aware of
how Aeolus is controlled. With the default instrument setup
there are around 55 'stops' wich can be switched ON or OFF
individually. In general Aeolus could have up to 256 of such
binary switches. Not all combinations make sense, but there
are still zillions of them that do. Such a system does not
map to anything standard in MIDI, but it is how a real pipe
organ is controlled.
5:28 p.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
On Tue, Oct 06, 2009 at 01:15:31PM -0400, Paul Davis wrote:
if aeolus is currently programmed to switch to stop
setting S1, and i
want it to switch setting S2 instead, what do i, as a user do? what do
i have to know?
There is no such thing as 'aeolus being programmed to switch to
some stop setting'.
Aeolus has the standard MIDI banks/presets, which you can
load/save from the GUI and recall using the normal MIDI
messages. In most cases that's all that's needed. It also
can use control message #98 to switch individual stops.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
7:21 p.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
On Tue, Oct 6, 2009 at 3:25 PM, Fons Adriaensen <fons(a)kokkinizita.net> wrote:
On Tue, Oct 06, 2009 at 01:15:31PM -0400, Paul Davis
wrote:
fons, i fully understood this, and was discussing means to set one or
more of the 55 stops.
my point was merely that requiring sysex to do this makes it much
harder for a user to
do this casually in an experimental way, but that may be oxymoronic :)
if aeolus is currently programmed to switch to
stop setting S1, and i
want it to switch setting S2 instead, what do i, as a user do? what do
i have to know?
There is no such thing as 'aeolus being programmed to switch to
some stop setting'.
Aeolus has the standard MIDI banks/presets, which you can
load/save from the GUI and recall using the normal MIDI
messages. In most cases that's all that's needed. It also
can use control message #98 to switch individual stops.
7:40 p.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
Paul Davis wrote:
But Fons is right that I didn't know this ;) and for this I agree that
SysEx is less user-friendly, but NRPNs are also not user-friendly,
unless Aeolus could send SysEx or NRPN by the GUI, so that a user
doesn't need to edit anything manually.
There is no
such thing as 'aeolus being programmed to switch to
some stop setting'.
Aeolus has the standard MIDI banks/presets, which you can
load/save from the GUI and recall using the normal MIDI
messages. In most cases that's all that's needed. It also
can use control message #98 to switch individual stops.
fons, i fully understood this
11:15 p.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
On Tue, 2009-10-06 at 23:40 +0200, Ralf Mardorf wrote:
Paul Davis wrote:
But Fons is right that I didn't know this ;) and for this I agree that
SysEx is less user-friendly, but NRPNs are also not user-friendly,
unless Aeolus could send SysEx or NRPN by the GUI, so that a user
doesn't need to edit anything manually.
Obviously an Aeolus controller/GUI would send whatever Aeolus ends up
supporting!
I don't see where your argument that a custom GUI would be /necessary/
comes from, this isn't true at all. Having a few tracks in a timeline
sequencer for specific stops you want to fiddle with throughout your
track is a perfectly reasonable thing to do.
-dr
There is
no such thing as 'aeolus being programmed to switch to
some stop setting'.
Aeolus has the standard MIDI banks/presets, which you can
load/save from the GUI and recall using the normal MIDI
messages. In most cases that's all that's needed. It also
can use control message #98 to switch individual stops.
fons, i fully understood this
11:08 p.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
On Tue, 2009-10-06 at 17:30 +0200, Nick Copeland wrote:
The issue with using the predefined CC such as #7 for
other uses is
that if any GM controller sits on your MIDI channel it will use that
as a volume control, and it will be reinterpreted by Aeolus as some
organ setting. The result is highly unpredictable and I don't think
there are 55 unassigned CC available.
The same is actually true of NRP: as the NRP has no concept of source
or dest other than the MIDI channel then if you want to control two
devices over the same channel (multilayered/multitimbral gives nice
results with a bit if detune) then the NRP are also going to collide.
This is just a silly thing to do in the first place, and I don't see how
it would really apply to Aeolus...
Out of interest, what was the problem with MIDI
sequencing and SYSEX?
The only problem I knew about was that they are atomic and cannot be
interupted hence on 'legacy' 5-pin DIN at a meagre few kilobaud there
were timing issues, largely overcome now with USB unless you want to
download gigasamples.
A sequencer knows a controller is a.... controller. It would be simple
to use any sequencer (or generic MIDI control thingie, or whatever) to
control that.
SYSEX is entirely meaningless binary blobs. At best you can make the
user (or developer) do a ton of device specific configuration to get any
sort of coherent control...
-dr
7 Oct
7 Oct
9:45 a.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
On Tue, 2009-10-06 at 17:30 +0200, Nick Copeland wrote:
Out of interest, what was the problem with MIDI
sequencing and SYSEX?
The only problem I knew about was that they are atomic and cannot be
interupted hence on 'legacy' 5-pin DIN at a meagre few kilobaud there
were timing issues, largely overcome now with USB unless you want to
download gigasamples.
For a given interface, you cannot send more midi-data down an USB line
than would fit in legacy midi, so the bottleneck still persists.
Otherwise you'd have created a standard that would overflow any
midi-endpoint connecting to the "real" world.
What you can do is to have up to 16 midi-endpoints (real or virtual
5-pin DIN) for each device in both directions.
If you know that the device is virtual and that it won't pass on any
messages to the next device, you can sometimes get away with sending
usb-midi at a higher rate. This has to be implemented at the driver
level though. FWIW, I had something like that going for a while on a
BCR2000 for subtle (fast switching) glow-in-the-dark effects as well as
flashing blinkenlights, using parameter feedback.
8 Oct
8 Oct
5:26 a.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
Jens M Andreasen wrote:
If you know that the device is virtual and that it
won't pass on any
messages to the next device, you can sometimes get away with sending
usb-midi at a higher rate. This has to be implemented at the driver
level though.
This is handled by the USB protocol: the host controller retries sending
a data packet until the device acknowledges it. In other words, the
driver can blast away at the device with lots of packets, but the actual
rate is never higher than the device can handle, so the driver doesn't
need to specifically know about your device.
Best regards,
Clemens
7:04 a.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
On Thu, 2009-10-08 at 09:26 +0200, Clemens Ladisch wrote:
This is handled by the USB protocol: the host
controller retries sending
a data packet until the device acknowledges it. In other words, the
driver can blast away at the device with lots of packets, but the actual
rate is never higher than the device can handle, so the driver doesn't
need to specifically know about your device.
Has this changed in the ALSA implementation? Because I remember that in
order to double the transfer rate to the BCR2000 I had to edit some
driver file (which one? I do not recall right now ...)
Also, wouldn't it be so that the USB interface in the device may
acknowledge that the package has arrived, but the device itself might
not have the compute power to deal with it and gives up because of
internal buffer overflows and errors? IIRC I was at first "blasting
away" at 16x using a sysex reflash of the prom as a speed test - which
fortunately did not brick the device, but neither did it show the
rotating "transfer in progress" pattern that it does otherwise[*].
Switching leds on/off at that speed did not work as expected either.
By settling for 2x instead I could then consistently display two red
dots on each of ten (rather than five) rotary controllers - one bright,
one dimmed - for, say showing course frequency as well as detune. For
several reasons though, I have since then abandoned that line of
thought ...
[*] At the start of the transfer it would show progress, but then after
a few seconds or so the display would just go blank ...
Best regards,
Clemens
10:02 a.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
Jens M Andreasen wrote:
On Thu, 2009-10-08 at 09:26 +0200, Clemens Ladisch
wrote:
In the latest driver version (ALSA 1.0.21 or kernel 2.6.32), the driver
now can submit multiple packets at the same time.
This is handled by the USB protocol: the host
controller retries sending
a data packet until the device acknowledges it. In other words, the
driver can blast away at the device with lots of packets, but the actual
rate is never higher than the device can handle, so the driver doesn't
need to specifically know about your device.
Has this changed in the ALSA implementation? Because I remember that in
order to double the transfer rate to the BCR2000 I had to edit some
driver file (which one? I do not recall right now ...) Also, wouldn't it be so that the USB interface in
the device may
acknowledge that the package has arrived, but the device itself might
not have the compute power to deal with it and gives up because of
internal buffer overflows and errors?
The device's firmware controls when to ACK a packet, so this should not
happen.
However, it is possible that USB support was later bolted on to a
device (or that the firmware writer is incompetent), and that the USB
chip communicates with the rest of the device over a line that has a
higher bandwidth than the main CPU can handle, and that nobody
implemented busy feedback. In that case, it woule be possible to lose
data after it has been correctly received over USB.
Best regards,
Clemens
6 Oct
6 Oct
10:47 a.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
Nick Copeland wrote:
Completely agree that SYSEX is where this kind of
functionality should
reside.
This use of 0x7d is a bit antiquated, no? The reassignment of 0x00 to
indicate 3 byte
SYSEX ID means there is a bit more flexibility in the system.
Currently the following
are assigned:
0x00 0x00 0xXX American group
0x00 0x01 0xXX American group
0x00 0x20 0xXX European group
0x4X Japanese group (with holes)
0x5X Japanese group (with holes)
0x00 0x04 Japanese group
Make the ID that will be sent or received after 0xf0 selectable by an
option menu. If there will be a conflict with any proprietary device,
someone could change the manufacture ID.
6:02 p.m.
New subject: [LAD] [LAU] So what's the deal with controlling the aeolus organ?stops via midi
On Monday, October 5, 2009, Nick Copeland wrote:
Getting a registration requires it be paid for, pretty
ludicrous for what
purports to be an open standard. I would suggest that Open Source
developers should simply take one of the unassigned values for its own
first digit, agree between themselves who get the next two digits for their
apps and SYSEX then be sent with 3 byte ID.
SLab hijacked 0x53 about 10 years ago for this purpose and bolted on a
three more digits for personal identification and there is little reason
why this should not be done again, this time in line with the current MMA
SYSEX ID defs as above? If open source goes and squats on 0x7d then
everybody can go and haggle over which app gets the next two digits.
The process for the sysex manufacturer ID registration is not only expensive
($200 per year) but also quite ridiculous. It is almost an invitation to
sysexquatting. Have you seen the "Recently Assigned Manufacturer ID Numbers"
page? http://www.midi.org/techspecs/manid.php
There are a lot of companies with a status of suspended, relinquished, renewal
pending ... In red, no less, to add embarrassment to the crisis?
Now, to tie this back into the original subject: this
does not really help
with assigning MIDI controllers back to app controls as now the surface has
to be configured to generate more complex SYSEX messages, neither easy nor
even possible with some of them
I agree. It doesn't help in many situations. However, sysex messages could be
used to store patches inside of MIDI files, attached to the music using the
patches. This can be done as well in Aelous with the current controller 98
messages. In either way, it won't be "easy peasy lemon squeezy".
Regards,
Pedro
7:20 p.m.
New subject: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
The process for the sysex manufacturer ID registration
is not only expensive
($200 per year) but also quite ridiculous. It is almost an invitation to
sysexquatting. Have you seen the "Recently Assigned Manufacturer ID Numbers"
page? http://www.midi.org/techspecs/manid.php
There are a lot of companies with a status of suspended, relinquished, renewal
pending ... In red, no less, to add embarrassment to the crisis?
There's no ID for e.g. Sequential Circuits (resp. I didn't take a look
at the complete list), a company that doesn't exist any more, but there
are still some synth used a lot, not only the old once without MIDI, but
also the later devices from the 80ies, shipped with MIDI by default. I
don't know Sequential's ID, but it would be bad, if e.g. a relative
young company like Waldorf should get Sequential's ID (by the way
Waldorf also isn't in the incomplete list).
We should "create" some kind of FLOSS agreement, e.g. let's chose some
unused ID's or some "bizarre" IDs, I guess some companies might be
uninteresting for music as a first ID and then e.g. create a list on
linuxaudio.org to register a second and third ID for FLOSS.
0xXY (MMA numbers used by us)
0xVW (linuxaudio.org registered number LO)
0xTU (linuxaudio.org registered number HI)
5520
days inactive
5523
days old
linux-audio-dev@lists.linuxaudio.org
34 comments
8 participants
participants (8)
-
Clemens Ladisch -
David Robillard -
Fons Adriaensen -
Jens M Andreasen -
Nick Copeland -
Paul Davis -
Pedro Lopez-Cabanillas -
Ralf Mardorf