Re: [Jsynthlib-devel] Yamaha S80 development?

[Daniel L. <soc...@ma...>]

----- Original Message -----
From: "Joe Emenaker" <jo...@em...>
To: jsy...@li...
Subject: Re: [Jsynthlib-devel] Yamaha S80 development?
Date: Sat, 30 Apr 2005 02:20:35 -0700


> >> Go right ahead. I haven't seen the S80 sysex spec anywhere. If=20
> >> you've got it, I'd appreciate a copy.
> >>
> >>
> > The data sheets from Yamaha do leave a bit to the imagination,
> >
> Oh yeah? I'll pit my Digitech Studio 400 "spec" against your Yamaha=20
> S80 any day! :)

My S80 is a lover, not a fighter!=20=20

>=20
> > but I think there's enough there to reverse engineer what isn't=20
> > in the documentation
> >
> For what it's worth, I wrote a hex-dump driver which makes it=20
> pretty easy to quickly slurp up a sysex dump and inspect it.=20
> Sometime in the future, I'd like to add the ability to do=20
> comparisons between two sysex's and have the hexdumper list all of=20
> the ranges that are different. That way, you could tweak a setting=20
> on the synth, do another sysex dump, and see what all changed.=20
> Could be handy for reverse-engineering.

Actually, that could be interesting to use.  I've only flipped through the =
MIDI specs and haven't programmed in them before, however - it looked like =
I might be able to separate out the commands from each other with a close i=
nspection.  As for the diff, if each byte or 2 byte sequence were on a diff=
erent line, you could just run diff over it.  Or, what I would do - is have=
 a PERL script make the files into 2 bytes per line, run diff, and strip th=
e output back into the original format.  Diff's luckily already got that al=
gorithm down, which might not be the simplist thing.

Could you send me a copy? :)

> I don't mean to start a religious war (and this ain't the place for=20
> it), but I'm just letting you know two of the things that kinda=20
> helped me "see the light" when moving from C++ to Java.

For this app the speed gains of C++ probably won't do much.  I've heard, fo=
r the record, that you can put a memory management package into C++ if it s=
uits your fancy (I haven't done this).  I tend to use PERL for everything n=
owadays, I've always wondered about pitting PERL against Java.  PERL actual=
ly first compiles the code into it's own internal format which it executes,=
 although there is no mechanism for passing this around (nor do I have a cl=
ue if it's platform independent).  Not that I'd really have the patience to=
 test the two against each other.

Cheers,
Dan

--=20
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm