need some help with MIDI::ALSA

[Andy]

Hi,
I discovered MIDI::ALSA yesterday and I'm really excited about it as Perl is
the only programming language I have some experience with and I always wanted
to write some MIDI tools (sysex dumpers and maybe an editor/librarian if I
ever find the time for it) that work in Linux with ALSA MIDI.

I tried out the example on http://search.cpan.org/~pjb/MIDI-ALSA-1.14/ALSA.pm
(the one in the synopsis) and the example on
http://showmetheco.de/articles/2011/12/learning-music-notes-with-perl.html and
they both work great, but when I tried to write my own basic test code I'm
having problems getting it to work.

Basically all I'm trying to do for now is write a few lines that send a single
note to a Roland JV-1080 connected via MIDI.

The following code appears to work but after the note off a message appears on
the display of the JV-1080 saying: "MIDI communication error"
(my setup works perfectly if I use Rosegarden to send a not to the JV-1080, no
error messages appear in that case so my Linux MIDI setup seems fine)

Here is the code I came up with:

#!/usr/bin/perl
use strict;
use warnings;

use MIDI::ALSA ('SND_SEQ_EVENT_PORT_UNSUBSCRIBED',
'SND_SEQ_EVENT_NOTEON',
'SND_SEQ_EVENT_NOTEOFF');

MIDI::ALSA::client('Perl MIDI test client',1,1,1);

MIDI::ALSA::connectto(1,28,2);

my @alsaevent = MIDI::ALSA::noteevent(1,32,100,0,0.5);
MIDI::ALSA::output( @alsaevent );

What is wrong with this code? Any idea why it causes that error on the JV-1080?

[Peter Billam]

On 2012-10-07, Andy <no...@none.none> wrote:
> I discovered MIDI::ALSA yesterday and I'm really excited about it as Perl
> is the only programming language I have some experience with and I always
> wanted to write some MIDI tools (sysex dumpers and maybe an editor/librarian
> if I ever find the time for it) that work in Linux with ALSA MIDI.
> I tried out the example on http://search.cpan.org/~pjb/MIDI-ALSA-1.14/ALSA.pm
> (the one in the synopsis) and the example on
> http://showmetheco.de/articles/2011/12/learning-music-notes-with-perl.html

I didn't know that one :-)

> The following code appears to work but after the note off a message
> appears on the display of the JV-1080 saying: "MIDI communication error"

> #!/usr/bin/perl
> use strict;
> use warnings;
> use MIDI::ALSA ('SND_SEQ_EVENT_PORT_UNSUBSCRIBED',
> 'SND_SEQ_EVENT_NOTEON',
> 'SND_SEQ_EVENT_NOTEOFF');
> MIDI::ALSA::client('Perl MIDI test client',1,1,1);
> MIDI::ALSA::connectto(1,28,2);
> my @alsaevent = MIDI::ALSA::noteevent(1,32,100,0,0.5);
> MIDI::ALSA::output( @alsaevent );

I think you need to start a queue in order for ALSA to be able to
schedule the corresponding NOTEOFF. The NOTEON gets transmitted OK
because it's at time=zero, but the NOTEOFF can't get scheduled.
So I guess your JV-1080 is complaining that it's received a NOTEON
with no corresponding NOTEOFF. This works for me:

use MIDI::ALSA;

MIDI::ALSA::client('Perl MIDI test client',1,1,1);

MIDI::ALSA::connectto(1,'Roland');
MIDI::ALSA::start();

my @alsaevent = MIDI::ALSA::noteevent(1,32,100,0,0.5);
MIDI::ALSA::output( @alsaevent );

MIDI::ALSA::syncoutput();

I think you also have to call syncoutput() to prevent the client
being destroyed before it has had time to transmit its NOTEOFF.

Hope this helps...

Regards, Peter
--
Peter Billam www.pjb.com.au www.pjb.com.au/comp/contact.html

[Andy]

Peter Billam wrote:
>
> use MIDI::ALSA;
> MIDI::ALSA::client('Perl MIDI test client',1,1,1);
> MIDI::ALSA::connectto(1,'Roland');
> MIDI::ALSA::start();
> my @alsaevent = MIDI::ALSA::noteevent(1,32,100,0,0.5);
> MIDI::ALSA::output( @alsaevent );
> MIDI::ALSA::syncoutput();
>
> I think you also have to call syncoutput() to prevent the client
> being destroyed before it has had time to transmit its NOTEOFF.
>
> Hope this helps...
>
> Regards, Peter

Thanks for your reply, even with the start() and the syncoutput() I still get
that weird "MIDI communication error" message on the display of the JV1080,
but after it has played the note (the MIDI led on the JV1080 flashes 3 times,
once for note-on and once for note-off and once right after that when the
error message appears). I'm puzzled about that but it doesn't matter really as
that was just a simple experiment with no real practical purpose.

I have now moved on to send sysex requests and then receive the related dumps
with a Yamaha RM50 synth and this works great for small sysex dumps (biggest
one that works fine is 1398 bytes, smallest one that doesn't is 6031 bytes),
but bigger ones have checksum mismatches.

The code I'm using is here (I started a thread about MIDI::ALSA on the LM
forum to spread the voice about this great Perl plugin):
http://www.linuxmusicians.com/viewtopic.php?f=44&t=10124

By the way are you a member of the LM forum? If not then I think you would
feel at home there!

In this case I'm confident that the problem is definitely NOT with MIDI::ALSA
as I tried doing the same sysex requests/dumps with 'amidi' and I get exactly
the same identical defective dumps that I get with my MIDI::ALSA Perl script
for dumps larger than 1398 bytes.
Also I tried using two different MIDI interfaces (a Midisport 4x4 and the MIDI
ports of a M-Audio Audiophile 2496 PCI card) each with a different set of MIDI
cables and each time I get exactly the same identical defective dumps back.

So either the Yamaha RM50 has a firmware flaw that affect larger sysex dumps
(I don't think so as the RM50 is a '90s synth when MIDI was already quite
mature, not some flakey '80s synth) or there is a problem in the ALSA stack
below the hardware drivers (as I tried two different MIDI interfaces).

I want to test this with a newer ALSA stack (I'm currently using a rather old
1.0.16) and maybe also Windows, but since I don't have a Windows PC this would
take some time.

Anyway I'm very glad that you created and released MIDI::ALSA as I had always
wanted to tinker around with MIDI programming on Linux but was never able to
before with Perl (and both C/C++ are too hard for me and I don't like Python
at all).

Regards,
Andy

[Peter Billam]

On 2012-10-10, Andy <no...@none.none> wrote:
> Peter Billam wrote:
>> use MIDI::ALSA;
>> MIDI::ALSA::client('Perl MIDI test client',1,1,1);
>> MIDI::ALSA::connectto(1,'Roland');
>> MIDI::ALSA::start();
>> my @alsaevent = MIDI::ALSA::noteevent(1,32,100,0,0.5);
>> MIDI::ALSA::output( @alsaevent );
>> MIDI::ALSA::syncoutput();
>

> Thanks for your reply, even with the start() and the syncoutput()
> I still get that weird "MIDI communication error" message on the
> display of the JV1080, but after it has played the note (the MIDI
> led on the JV1080 flashes 3 times, once for note-on and once for
> note-off and once right after that when the error message appears).

Maybe it's signalling there's been a PORT_UNSUBSCRIBED event?
Perhaps you could try adding a sleep 5; after the syncoutput();
to see if the error message comes 5 seconds later ?
Or disconnectto() and then sleep another 5 to see when the
message appears. Or disconnect by hand aconnect -d Perl Roland

> The code I'm using is here (I started a thread about MIDI::ALSA
> on the LM forum to spread the voice about this great Perl plugin):
> http://www.linuxmusicians.com/viewtopic.php?f=44&t=10124

May it be useful :-)

> By the way are you a member of the LM forum?
> If not then I think you would feel at home there!

I'll lurk for a bit and see what happens. I prefer newsgroups as
a user-experience. I wish forum sites would offer news interfaces.

> Anyway I'm very glad that you created and released MIDI::ALSA as I
> had always wanted to tinker around with MIDI programming on Linux but
> was never able to before with Perl (and both C/C++ are too hard for
> me and I don't like Python at all).

I'd always wanted to; it was Patricio Paez' Python modules that
were the breakthrough for me, I was able to recycle his C code
and just change the glue. My favourite language, as a language,
is Lua, but Perl is still a great workhorse, and CPAN is important.

Good luck with your sysex checksums...

[Andy]

Peter Billam wrote:
> Maybe it's signalling there's been a PORT_UNSUBSCRIBED event?
> Perhaps you could try adding a sleep 5; after the syncoutput();
> to see if the error message comes 5 seconds later ?
> Or disconnectto() and then sleep another 5 to see when the
> message appears. Or disconnect by hand aconnect -d Perl Roland

Ok, I did the following test now:
------------------------------------------------------

#!/usr/bin/perl
use strict;
use warnings;

use MIDI::ALSA ('SND_SEQ_EVENT_PORT_UNSUBSCRIBED',
'SND_SEQ_EVENT_NOTEON',
'SND_SEQ_EVENT_NOTEOFF');

MIDI::ALSA::client('Perl MIDI test client',1,1,1);

MIDI::ALSA::connectto(1,32,2);
MIDI::ALSA::start();

my @alsaevent = MIDI::ALSA::noteevent(1,32,100,0,1);

MIDI::ALSA::output( @alsaevent );

my @alsaevent = MIDI::ALSA::noteevent(1,32,100,2,1);

MIDI::ALSA::output( @alsaevent );

sleep 5;
print "syncoutput\n\n";
MIDI::ALSA::syncoutput();

sleep 5;
print "disconnectto\n\n";
MIDI::ALSA::disconnectto(1,32,2);

sleep 5;
print "the end\n";
------------------------------------------------------
and the last JV1080 MIDI LED flash followed by the "MIDI communication error"
message shows up right after the MIDI::ALSA::disconnectto(1,32,2) is being sent.
If I remove the the disconnectto() then the MIDI LED flash and error mesage
happen right after the program exits.

So it seems something is being sent to the synth at disconnect/end-of-program,
that the synth doesn't like. I hope this info is enough for you to guess what
might be wrong?

> I'll lurk for a bit and see what happens. I prefer newsgroups as
> a user-experience. I wish forum sites would offer news interfaces.

I prefer news interfaces to web based forums too, but there is almost nobody
left on newsgroups these days... :-(

Andy

[Andy]

Hi Peter,

I just discovered something that has puzzled me the last few days when I was
trying to send MIDI events to some synths that only receive on one specific
MIDI channel.

In MIDI::ALSA the $ch (midi channel) variable is defined from 0-15 (as opposed
to the normal 1-16), can you please mention that on the MIDI::ALSA CPAN
documentation as I'm sure it will keep others from spending hours wondering
why things don't work as expected!

Thanks!

[Andy]

Hi,
sorry for the amount of posts today, but I think I found a bug in MIDI::ALSA
with regards to the refering to clients by name in connectfrom() and connectto().

I have the following setup:
$ aseqdump -l
Port Client name Port name
0:0 System Timer
0:1 System Announce
14:0 Midi Through Midi Through Port-0
20:0 M Audio Audiophile 24/96 M Audio Audiophile 24/96 MIDI
24:0 Virtual Raw MIDI 2-0 VirMIDI 2-0
25:0 Virtual Raw MIDI 2-1 VirMIDI 2-1
26:0 Virtual Raw MIDI 2-2 VirMIDI 2-2
27:0 Virtual Raw MIDI 2-3 VirMIDI 2-3
28:0 Midisport 2x2 Midisport 2x2 MIDI 1
28:1 Midisport 2x2 Midisport 2x2 MIDI 2
32:0 MidiSport 4x4 MidiSport 4x4 MIDI 1
32:1 MidiSport 4x4 MidiSport 4x4 MIDI 2
32:2 MidiSport 4x4 MidiSport 4x4 MIDI 3
32:3 MidiSport 4x4 MidiSport 4x4 MIDI 4
36:0 PC-50 PC-50 MIDI 1

If I refer to clients by port number all works well, I can address all of the
individual ports of the Midisport 2x2 and the MidiSport 4x4.

But if I refer to them like this:
MIDI::ALSA::connectto(1,'MidiSport 4x4',3)
or even abbreviated like this:
MIDI::ALSA::connectto(1,'MidiSport',3)
then the connection will always be to the first port (32:0) never to the other
ports of the MidiSport 4x4, regardless of what src_port/dest_port number I
give as third parameter (same happens for the Midisport 2x2).

So basically when refering to clients by name (which obviously is much more
convenient than using numbers as the numbers change between sessions) I'm
unable to address any MIDI ports apart from the first one of the device.

Regards, Andy

[Peter Billam]

On 2012-10-10, Andy <no...@none.none> wrote:

> the last JV1080 MIDI LED flash followed by the "MIDI communication error"
> message shows up right after the MIDI::ALSA::disconnectto(1,32,2) is
> being sent. If I remove the the disconnectto() then the MIDI LED flash
> and error mesage happen right after the program exits.
>
> So it seems something is being sent to the synth at
> disconnect/end-of-program, that the synth doesn't like.

The System sends it a SND_SEQ_EVENT_PORT_UNSUBSCRIBED event

> I hope this info is enough for you to guess what might be wrong?

Nothing's wrong; it's a situation that might be an emergency if
you're performing on stage and the guitarist gets tangled up in
your midi-cable, but at the software-client level it happens
all the time; it's a feature, it's what aconnect -d does.
A more helpful warning-message might have been e.g.
"Warning: one of my inputs got disconnected; hope this is OK..."

>> I'll lurk for a bit and see what happens. I prefer newsgroups as
>> a user-experience. I wish forum sites would offer news interfaces.
> I prefer news interfaces to web based forums too, but there
> is almost nobody left on newsgroups these days... :-(

There is at least yourself.

Regards, Peter

[Peter Billam]

On 2012-10-10, Andy <no...@none.none> wrote:

> But if I refer to them like this:
> MIDI::ALSA::connectto(1,'MidiSport 4x4',3)
> or even abbreviated like this:
> MIDI::ALSA::connectto(1,'MidiSport',3)
> then the connection will always be to the first port (32:0) never to the other
> ports of the MidiSport 4x4, regardless of what src_port/dest_port number I
> give as third parameter (same happens for the Midisport 2x2).
>
> So basically when refering to clients by name (which obviously is much more
> convenient than using numbers as the numbers change between sessions) I'm
> unable to address any MIDI ports apart from the first one of the device.

The doc says:
Since version 1.11, and unlike in the alsaseq.py Python module,
if dest_client is a string and dest_port is undefined, <===
then parse_address(dest_client) automatically gets invoked.
This allows you to refer to the clients by name, for example
connectfrom(inputport,'Virtual:1')
will connect from port 1 of the 'Virtual Raw MIDI' client.

so
MIDI::ALSA::connectto(1,'MidiSport:3')
ought to work. If you feed it connectto(1,'MidiSport',3) then the
dest_port is not undefined, so it will probably try to connect to 0:3

[Peter Billam]

On 2012-10-10, Andy <no...@none.none> wrote:

> I just discovered something that has puzzled me the last few days
> when I was trying to send MIDI events to some synths that only receive
> on one specific MIDI channel.
> In MIDI::ALSA the $ch (midi channel) variable is defined from 0-15

This is true.

> (as opposed to the normal 1-16),

Well, it depends what you mean by normal.

> can you please mention that on the MIDI::ALSA CPAN documentation

It's not there explicitly, is it... It's implied by:
The data array is mostly as documented in
http://alsa-project.org/alsa-doc/alsa-lib/seq.html
but that's a bit subtle. It deserves an explicit mention.
Thanks for pointing this out.

[Andy]

Peter Billam wrote:
>
> The doc says:
> Since version 1.11, and unlike in the alsaseq.py Python module,
> if dest_client is a string and dest_port is undefined, <===
> then parse_address(dest_client) automatically gets invoked.
> This allows you to refer to the clients by name, for example
> connectfrom(inputport,'Virtual:1')
> will connect from port 1 of the 'Virtual Raw MIDI' client.
>
> so
> MIDI::ALSA::connectto(1,'MidiSport:3')
> ought to work. If you feed it connectto(1,'MidiSport',3) then the
> dest_port is not undefined, so it will probably try to connect to 0:3

Ok I see now, I did read that doc, but I didn't get the fact that I had to put
the port together with the device name.
Sorry my bad, I clearly didn't pay enough attention when reading it, thanks
for clarifying this.

[Andy]

Peter Billam wrote:
> On 2012-10-10, Andy <no...@none.none> wrote:
>> (as opposed to the normal 1-16),
>
> Well, it depends what you mean by normal.

Well normal for me is what appears on the display of the synths (and in their
manuals) and what the sequencer software packages use. All these normally
count the midi channels from 1 to 16, I have never seen one that starts the
count of the midi channels from zero.

I understand that in the programming world it's common to start from zero and
this is something that you simply took over from the ALSA libs so I do
understand why this is the way it is in MIDI::ALSA (it just took me a while to
figure out in the first place...).

> It's not there explicitly, is it... It's implied by:
> The data array is mostly as documented in
> http://alsa-project.org/alsa-doc/alsa-lib/seq.html
> but that's a bit subtle. It deserves an explicit mention.
> Thanks for pointing this out.

Thanks, I think it will be helpful for others if it's explicitly mentioned.

[Andy]

Peter Billam wrote:
> The System sends it a SND_SEQ_EVENT_PORT_UNSUBSCRIBED event

Do you happen to know what that means expressed in raw MIDI data?
I did a quick search but I couldn't find this explained anywhere.

> Nothing's wrong; it's a situation that might be an emergency if
> you're performing on stage and the guitarist gets tangled up in
> your midi-cable, but at the software-client level it happens
> all the time; it's a feature, it's what aconnect -d does.
> A more helpful warning-message might have been e.g.
> "Warning: one of my inputs got disconnected; hope this is OK..."

Ok I see, thanks for the explanation, so basically in my case I can just
ignore the message.

> There is at least yourself.

Only because I saw that you are on here. :-)
Seriously, I hadn't used Usenet in ages, I had quite a hard time finding a
free open-access Usenet provider since my ISP doesn't provide a Usenet server
any more.

[Peter Billam]

On 2012-10-10, Andy <no...@none.none> wrote:

> Peter Billam wrote:
> > The System sends it a SND_SEQ_EVENT_PORT_UNSUBSCRIBED event
> Do you happen to know what that means expressed in raw MIDI data?
> I did a quick search but I couldn't find this explained anywhere.

It's not expressible in raw midi data; it's an ALSA thing that
informs the ALSA client that represents your synth; the information
must get conveyed to the synth by something in the midi usb driver,
I don't know anything about this. AFAIK, the old DIN-plug midi
cables used a current-loop to transmit the data, so they would
have been able to detect whether there was anything plugged in the
other end of the cable or not, so I can imagine people would want to
give the usb driver equivalent functionality... But just guessing...

[Andy]

Ok, thanks, I do think the ALSA USB MIDI driver is sending it as actual MIDI
message to the synth as the MIDI message LED flashes briefly at that point,
but I guess knowing the exact MIDI message doesn't really matter.

Anyway, I did complete the sysex bulk dumper for the Yamaha RM50 using
MIDI::ALSA, it works fine now and (in case you are curious) I posted it here:
http://www.linuxmusicians.com/viewtopic.php?f=44&t=10145

Regards,
Andy

[Peter Billam]

On 2012-10-14, Andy <no...@none.none> wrote:
> Anyway, I did complete the sysex bulk dumper for the Yamaha RM50 using
> MIDI::ALSA, it works fine now and (in case you are curious) I posted it here:
> http://www.linuxmusicians.com/viewtopic.php?f=44&t=10145

Nice. But I have absolutely no way of ever testing it :-(

I can imagine it testing what synth it's connecting from,
and adapting its sysex request strings accordingly...

Would you like to add a pod to the end so that
perldoc bulk_dumper.pl
works ? Maybe take
http://www.pjb.com.au/tmp/bulk_pod
as a start ?
Could I link to it in the See Also of MIDI::ALSA's perldoc ?

[Andy]

Peter Billam wrote:
> On 2012-10-14, Andy <no...@none.none> wrote:
>> Anyway, I did complete the sysex bulk dumper for the Yamaha RM50 using
>> MIDI::ALSA, it works fine now and (in case you are curious) I posted it here:
>> http://www.linuxmusicians.com/viewtopic.php?f=44&t=10145
>
> Nice. But I have absolutely no way of ever testing it :-(

Yeah sorry, I'm not even sure if there is any other Yamaha RM50 owner out
there who uses Linux (given that the RM50 isn't exactly common by itself).

> Would you like to add a pod to the end so that
> perldoc bulk_dumper.pl
> works ? Maybe take
> http://www.pjb.com.au/tmp/bulk_pod
> as a start ?

Many thanks for that template, I might consider adding a pod in future, right
now this script is still way to basic to deserve that, my idea is to make it a
fully featured editor/librarian for the RM50 (but I don't know if I will be
able to dedicate enough time to it to get to that stage).

> Could I link to it in the See Also of MIDI::ALSA's perldoc ?

Certainly, please link to the related linuxmusicians forum thread, not
directly to the script, so that I can still move the script to some other
place (maybe github if the script ever becomes useful enough to deserve that)
without breaking your link (I would then simply update the link in the forum
thread).

[Andy]

Andy wrote:
> my idea is to make it a
> fully featured editor/librarian for the RM50 (but I don't know if I will be
> able to dedicate enough time to it to get to that stage).

Peter, if you want have a look at what I believe is the first program (other
than those written by yourself of course) that makes use of the MIDI::ALSA
library.

It's the Yamaha RM50 Editor/Librarian I have been working on, it's far from
finished but it is already functional and thanks to MIDI::ALSA allows real
time editing via MIDI of every single parameter of RM50 patches.

Here it is (beware it unzips into the current directory):
http://www.linuxtech.net/files/rm50_manager.zip
There are a few example patches (in sysex) format that you can load included.
Currently you need to run it out of the directory where you extract it to,
otherwise it won't find the jpg image used by the program.

Like I said it's far from finished and it currently still has the MIDI port
hard-coded so to make use of the MIDI functionality it would be necessary to
edit that near the beginning of the code (and of course to use the MIDI
functionality it requires a Yamaha RM50 synth).

I guess this might have been the kind of app you had in mind when writing
MIDI::ALSA, it certainly is what I always wanted to write but was unable to
due to lack of a proper Perl MIDI library for Linux (and my lack of knowledge
of any other programming language...).

After I complete the Yamaha RM50 Editor/Librarian I intend to write some more
Editor/Librarian for other synths I have access to.

[Andy]

Andy wrote:
> Peter, if you want have a look at what I believe is the first program (other
> than those written by yourself of course) that makes use of the MIDI::ALSA
> library.

Actually I have done the first proper release now, more details here:
http://www.yamahaforums.co.uk/forum/viewtopic.php?f=9&t=5915

[Tonton Th]

Who, nice ! Need the same for my tx81z \o_

--

Nous vivons dans un monde étrange/
http://foo.bar.quux.over-blog.com/

[Andy]

Tonton Th wrote:
> On 11/12/2012 08:44 AM, Andy wrote:
>
>>> Peter, if you want have a look at what I believe is the first program
>>> (other
>>> than those written by yourself of course) that makes use of the
>>> MIDI::ALSA
>>> library.
>>
>> Actually I have done the first proper release now, more details here:
>> http://www.yamahaforums.co.uk/forum/viewtopic.php?f=9&t=5915
>
> Who, nice ! Need the same for my tx81z \o_
>

Well I don't have a TX81Z, but if you donate one to me I would be happy to
write a similar voice editor for the TX81Z. :)

[Peter Billam]

On 11/12/2012 08:44 AM, Andy wrote:
>> Peter, if you want have a look at what I believe is the first
>> program (other than those written by yourself of course) that
>> makes use of the MIDI::ALSA library.
> Actually I have done the first proper release now, more details here:
> http://www.yamahaforums.co.uk/forum/viewtopic.php?f=9&t=5915

Look good :-) May it be useful !

On that link you say:
> Thanks to Sonus for his assistance in helping me understand
> the MIDI/Sysex implementation of the RM50

That's presumably the hard bit, those Sysex interfaces seem
very undocumented. Where do you go to find out about them ?

> Well I don't have a TX81Z, but if you donate one to me I would
> be happy to write a similar voice editor for the TX81Z. :)

Really, every synth that's ever been manufactured needs the same.
(Mine would be a Roland XV-2020) If they're all separate apps,
the core code has to be maintained in many forks; if they're all
rolled into one cross-synth app then it'll become very big...
In either case the synth-specific functionality should be kept
as separate as possible from the core code: not always easy.

Maybe there's enough in common between different synths of the
same manufacturer to roll them into one manufacturer-specific app,
or maybe there's enough in common globally, I don't know this Sysex
world. What d'you reckon, Andy ?

Regards, Peter

[Andy]

Peter Billam wrote:
> On 11/12/2012 08:44 AM, Andy wrote:
>>> Peter, if you want have a look at what I believe is the first
>>> program (other than those written by yourself of course) that
>>> makes use of the MIDI::ALSA library.
>> Actually I have done the first proper release now, more details here:
>> http://www.yamahaforums.co.uk/forum/viewtopic.php?f=9&t=5915
>
> Look good :-) May it be useful !
>
> On that link you say:
>> Thanks to Sonus for his assistance in helping me understand
>> the MIDI/Sysex implementation of the RM50
>
> That's presumably the hard bit, those Sysex interfaces seem
> very undocumented. Where do you go to find out about them ?

Actually both Yamaha and Korg do document their Sysex interfaces quite well,
you usually find the sysex documentation on the last few pages of the
manual that comes with the synth (that's where I got the info from).

Judging by the manual of my Roland JV-1080 on the other hand Roland's
sysex documentation is a true mess. While it looks complete, it looks
very cryptic to me, not very readable and understandable.
Maybe it's better for the XV-2020 since that synth is newer?

>> Well I don't have a TX81Z, but if you donate one to me I would
>> be happy to write a similar voice editor for the TX81Z. :)
>
> Really, every synth that's ever been manufactured needs the same.

Indeed, but there are already some synth specific editors/sysex managers
available for Linux, see this thread:
http://www.linuxmusicians.com/viewtopic.php?f=19&t=6898

> (Mine would be a Roland XV-2020) If they're all separate apps,
> the core code has to be maintained in many forks; if they're all
> rolled into one cross-synth app then it'll become very big...
> In either case the synth-specific functionality should be kept
> as separate as possible from the core code: not always easy.
>
> Maybe there's enough in common between different synths of the
> same manufacturer to roll them into one manufacturer-specific app,
> or maybe there's enough in common globally, I don't know this Sysex
> world. What d'you reckon, Andy ?

General sysex managers that have plugins for specific synths do exist (mostly
for Windows/Mac but there is Jsynthlib written in Java that allegedly works on
Linux too, I never managed to get it working though) but IMHO that approach is
both extremely complex from a programmer point of view (you need to have a
very good understanding of a lot of synths and their various sysex
implementations to build a comprehensive abstraction model) and often comes
with compromises for the user, so I'm not keen on that approach.

Of course there is some code that can be shared (and maybe once I start
writing my second sysex manager, most likely for the Korg X5DR or the Oberheim
Matrix 1000) I will spot some code that I can put into a common .pm to be used
by both sysex managers, but trying to make the code as abstract as possible to
suit as many synths as possible is IMHO more hassle than it's worth.

One thing I found out though, you need to own or have access to the synth you
are programming for as the sysex documentation is never 100% complete (so some
things you can only find out by experimentation) and also usually contains
some errors.

[Peter Billam]

On 2012-11-14, Andy <no...@none.none> wrote:
> you usually find the sysex documentation on the last few pages of the
> manual that comes with the synth (that's where I got the info from).
> Judging by the manual of my Roland JV-1080 on the other hand Roland's
> sysex documentation is a true mess. While it looks complete, it
> looks very cryptic to me, not very readable and understandable.
> Maybe it's better for the XV-2020 since that synth is newer?

Well I guess that's it on pages 146-157; there's no mention of
being related to sysexes, it's titled (their spelling):
3. Parameter Address Map
* Transmission of "#" marked packets is diviedd to some packets.
For example, ABH in hexadecimal notation will be divied to
0AH and 0BH and is sent/received in this order.
* "<*>" marked addresses or parameters are ignored when
the XV-2020 received them.
1. XV-2020 (ModelID = 00H 10H)

and then eleven pages of tables, the first with columns "Start
Address" and "Description" and the others with "Offset Address"
and "Description" It's all in a micro-font in a medium-grey ink
and would be only just photocopiable...

> Of course there is some code that can be shared ... I will spot

> some code that I can put into a common .pm to be used by both sysex
> managers, but trying to make the code as abstract as possible to
> suit as many synths as possible is IMHO more hassle than it's worth.

That's the kind of way I'd approach it, too.

> One thing I found out though, you need to own or have access
> to the synth you are programming

I really can't send you mine, I use it too much, but if you get
your hands on a second-hand XV-2020 without a manual, let me know...

[Andy]

Peter Billam wrote:
> On 2012-11-14, Andy <no...@none.none> wrote:
>> you usually find the sysex documentation on the last few pages of the
>> manual that comes with the synth (that's where I got the info from).
>> Judging by the manual of my Roland JV-1080 on the other hand Roland's
>> sysex documentation is a true mess. While it looks complete, it
>> looks very cryptic to me, not very readable and understandable.
>> Maybe it's better for the XV-2020 since that synth is newer?
>
> Well I guess that's it on pages 146-157; there's no mention of
> being related to sysexes, it's titled (their spelling):
> 3. Parameter Address Map
> * Transmission of "#" marked packets is diviedd to some packets.
> For example, ABH in hexadecimal notation will be divied to
> 0AH and 0BH and is sent/received in this order.
> * "<*>" marked addresses or parameters are ignored when
> the XV-2020 received them.
> 1. XV-2020 (ModelID = 00H 10H)
>
> and then eleven pages of tables, the first with columns "Start
> Address" and "Description" and the others with "Offset Address"
> and "Description" It's all in a micro-font in a medium-grey ink
> and would be only just photocopiable...

Yes, that's the sysex documentation, I'm not too surprised that Roland still
presents it in the same cryptic style as they did in 1994 for the JV-1080.

Out of curiosity I downloaded the pdf manual of the XV-2020 and compared the
sysex documentation to the one for the JV-1080 and found that (at least at
first glance) the sysex implementation looks very similar, so a patch editor
for the JV-1080 would likely mostly work for the XV-2020 too and viceversa
(with only small modifications).

Theoretically if you ever decided to write an editor for the XV-2020 I could
contribute to it to make it compatible with the JV-1080 too, but I'm still not
too keen to start studying the Roland sysex documentation...

Right now I prefer to stick to better documented synths from Yamaha and Korg.

> I really can't send you mine, I use it too much, but if you get
> your hands on a second-hand XV-2020 without a manual, let me know...

Unlikely since I already have the JV-1080 which is very similar to your
XV-2020 so I don't have any need for a XV-2020 in addition to the JV-1080.

Andy