Re: [Jsynthlib-devel] Yamaha S80 development?

[Joe E. <jo...@em...>]

Daniel Lyons wrote:

>Well, the JSynthLib developer docs said to check the RFE first.  Heh, I dont know - i assumed since it was 'assigned' to someone that meant something.
>
Well... it should have meant something... but it doesn't. The guy who 
suggested using the RFE's to signify "intent to write" assigned the 
projects to the people who submitted them.... but, like you say... oh well.

>>Go right ahead. I haven't seen the S80 sysex spec anywhere. If 
>>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 S80 
any day! :)

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

> so... I figured there might be hope for Java after all! 
>(multiple inheritance rocks the universe, though, they'll never understand that).
>  
>
When I first read about Java, I was horrified. I warmed up to it, 
though. The two main complaints I hear about it (and my responses to 
them) are:
1 - No multiple inheritance: True, but when I read Gosling's 
justification for it, I felt that the man had a true moment of 
inspiration. He noted that the vast majority of the time people use 
multiple inheritance, it isn't because they really need to "inherit" 
anything but because their class needs to advertize that it implements 
certain methods (ie, so that other classes know that they can *call* 
method "xyz"). For that, Gosling made interfaces... and I consider that 
a stroke of incredible insight.
2 - Java is slow: This is true as well. However, this problem goes away 
with time. By that I mean... go write a program in Java and another C++. 
Suppose that the Java program is slow and that the C++ one has memory 
leaks or, even worse, dangling pointers. If you put them on the shelf 
and wait a year and then come back, the Java program will probably be 
usable (still not as fast as the C++, but fast enough to use now), yet 
the C++ will still have the memory leaks and dangling pointers. In 
short, we'll always have faster processors, but we'll never have 
processors that magically figure out what the programmer *meant* to do.

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

>>So, if you get stuck anywhere... don't hesitate to let me know.
>>    
>>
>I'll take that as a green light.  Alright, if I find myself shaking my
>fist too much, you'll have one frustrated nerd e-mailing you :)
>  
>
Read the archives from a couple of months ago... the list has already 
had a frustrated nerd emailing *them*. I guess I'm due for my pennance.

- Joe