Discussion:
[LAD] [LAU] So what's the deal with controlling the aeolus organ?stops via midi
Nick Copeland
16 years ago
Permalink
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
...
"we have to make sure the old choice [Windows] doesn't disappear”.
Jim Wong, president of IT products, Acer
...
_________________________________________________________________
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/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_2:092009
David Robillard
16 years ago
Permalink
Post by Nick Copeland
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
Clemens Ladisch
16 years ago
Permalink
Post by David Robillard
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
Paul Davis
16 years ago
Permalink
Post by Clemens Ladisch
Post by David Robillard
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.
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.
Ralf Mardorf
16 years ago
Permalink
Post by Paul Davis
Post by Clemens Ladisch
Post by David Robillard
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.
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.
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.
Paul Davis
16 years ago
Permalink
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.
Ralf Mardorf
16 years ago
Permalink
Post by Paul Davis
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.
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.
Nick Copeland
16 years ago
Permalink
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
...
_________________________________________________________________
Windows Live: Keep your friends up to date with what you do online.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_1:092010
Ralf Mardorf
16 years ago
Permalink
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.
Paul Davis
16 years ago
Permalink
On Tue, Oct 6, 2009 at 11:30 AM, Nick Copeland
Post by Nick Copeland
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.
Ralf Mardorf
16 years ago
Permalink
Post by Paul Davis
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.
Paul Davis
16 years ago
Permalink
Post by Ralf Mardorf
Post by Paul Davis
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.
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?
Ralf Mardorf
16 years ago
Permalink
Post by Paul Davis
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 ;).
Paul Davis
16 years ago
Permalink
...
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) ?
Ralf Mardorf
16 years ago
Permalink
Post by Paul Davis
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.
Fons Adriaensen
16 years ago
Permalink
Post by Ralf Mardorf
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.
Ralf Mardorf
16 years ago
Permalink
...
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.
Fons Adriaensen
16 years ago
Permalink
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.
Ralf Mardorf
16 years ago
Permalink
...
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
Fons Adriaensen
16 years ago
Permalink
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.
David Robillard
16 years ago
Permalink
...
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
Fons Adriaensen
16 years ago
Permalink
Post by Paul Davis
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.
Paul Davis
16 years ago
Permalink
...
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 :)
Ralf Mardorf
16 years ago
Permalink
Post by Paul Davis
Post by Fons Adriaensen
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
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.
David Robillard
16 years ago
Permalink
...
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
David Robillard
16 years ago
Permalink
...
This is just a silly thing to do in the first place, and I don't see how
it would really apply to Aeolus...
Post by Nick Copeland
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
Jens M Andreasen
16 years ago
Permalink
Post by Nick Copeland
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.
Clemens Ladisch
16 years ago
Permalink
Post by Jens M Andreasen
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
Jens M Andreasen
16 years ago
Permalink
Post by Clemens Ladisch
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 ...
Post by Clemens Ladisch
Best regards,
Clemens
Clemens Ladisch
16 years ago
Permalink
...
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.
Post by Jens M Andreasen
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

Ralf Mardorf
16 years ago
Permalink
Post by Nick Copeland
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
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.
Nick Copeland
16 years ago
Permalink
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
...
_________________________________________________________________
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/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_2:092009
Ralf Mardorf
16 years ago
Permalink
Post by Nick Copeland
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.)"
Pedro Lopez-Cabanillas
16 years ago
Permalink
...
The only devices or programs that would be screwed are those bad or poorly
designed/written.

In addition to the manufacturer ID, there should be enough additional bytes to
uncertainly identify a particular model among others using the same
manufacturer ID. The device (soft in this case) receiving a message should be
able to distinguish between legitimate and spurious messages using the model
ID bytes, checksums and/or some other mechanism.

Regards,
Pedro
Fons Adriaensen
16 years ago
Permalink
Post by Pedro Lopez-Cabanillas
In addition to the manufacturer ID, there should be enough additional bytes to
uncertainly identify a particular model among others using the same
manufacturer ID.
Sure, e.g. four unique bytes at the start would solve
the problem. But there is no central authority in the
open source world to assign them.

A truly random sequence of 8 or more bytes would work
as well. But it means that even transmitting seven bits
requires 11 bytes. No problem for system dumps etc., but
for frequent short messages the overhead is too much.

Ciao,
--
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.
Ralf Mardorf
16 years ago
Permalink
...
Checksums are not always used for simple parameters, I guess they are
used for complete dumps and the model number or device number also could
have a FLOSS-twin. For e.g. the Matrix-1000 you can have several
Oberheim Matrix-1000 and give them device numbers, so that only one
Matrix-1000 will use received data. It would be really good if there
would be a first ID for FLOSS, but there isn't, so it might be the best
way to make this ID changeable by the GUI.
Pedro Lopez-Cabanillas
16 years ago
Permalink
...
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?
Post by Nick Copeland
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
Ralf Mardorf
16 years ago
Permalink
Post by Pedro Lopez-Cabanillas
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)
Loading...