jsynthlib-devel — Mailing list for developers and users interested in improving the JSynthLib.

Re: [Jsynthlib-devel] Interfaces

[Hiroo H. <hir...@co...>]

Hi Rib,

I have to go office soon.  Quick answer.

Rib> Hi Hiroo.  I have a couple questions/comments about these changes.
Rib> First, in Patch(byte[], int) it looks like it should be
Rib> System.arraycopy(sysex, offset, this.sysex, 0, sysex.length - offset);
Rib> instead of
Rib> System.arraycopy(sysex, offset, sysex, 0, sysex.length - offset);
You are correct.  But now Patch(byte[], int) is not used by my last
change.  We can remove this constructor.

Rib> Also, I was thinking it might be better to have
Rib> IPatchDriver.supportsMessage so that each message can be checked
Rib> instead of just whatever's at the beginning.  Then it would probably
Sorry, I don't understand the purpose of this method.  Does this check
if IPatch.getDriver() returned correct value?  (I guess this is wrong.)

Rib> be better to have something like Patch.chooseDriver(SysexMessage[])
Rib> and Patch.valueOf(SysexMessage[]). Should these be final?
I did not defined them just because I did not need them to reimplement
the current JSynthLib.  If we need them, let's define.

I've not sure this is the case, but I agree with you we should use more
'final' properly.  It will help synth driver developers.

Rib> I had one other question about Converter, but I figured it out. 
Rib> Should I go back include my changes to my Converter extend Object now?
I'm not sure.

If Converter extends Object (not Driver), don't you have to make change
the subclasses of the Converter?  I start thinking Driver, BankDriver,
Convert, and Patch classes are for compatibility.  I guess you may need
AbstractConverter class.  I also think we may need AbstractPatch class
for common methods of Patch and XMLPatch class.

Rib> I was working on the xml driver today. I'd guess it's about 40% done.  
Good to hear!
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] Sending CC Messages and Disabled Edit Menu

[Jeff W. <jww...@ya...>]

Hiroo,
 
About your question, "Does not SysexMessage.setMessage throw InvalidMidiDataException? It's interesting.":
You're right, it does throw InvalidMidiDataException, but the setMessage call is in a try/catch block and the catch block just calls ErrorMsg.reportStatus(e).
 
About your comment, "The method I sent you returns an array of MidiMessage (if it works as I expect:-)). You can send each of them by using driver.send().":
Thanks, I'll give that a try. I'll let you know how it goes.
 
About your question, "How did you list up the lots of drivers of the kind?":
I'm doing my development on a Mac using the XCode tool. XCode has a few nice features, one of which is a find/grep function that lets me search through whole projects or frameworks. I just searched the Synthdrivers directory looking for the string "SysexSender" to see which drivers were subclassing it. But then I only actually looked at about 3 or 4 of them and none of the ones I happened to look at were sending CC messages. Maybe I should have looked at little harder?  
 
Thanks,
Jeff


Hiroo Hayashi <hir...@co...> wrote:
From: Hiroo Hayashi 
To: JSynthLib Development 
Subject: Re: [Jsynthlib-devel] Sending CC Messages and Disabled Edit Menu
Date: Mon, 23 Aug 2004 21:47:34 -0500

Jeff,

I assumed that SysexMessage[] MidiUtil.byteArrayToSysexMessages() was
used and I made a replacement for it. Sorry for confusing you.

Jeff> I'm not sure I understand your message. I don't think
Jeff> the problem is in the SysexSender but rather in the
Jeff> SysexWidget.sendSysex method. To restate my original
Jeff> message, first SysexWidget.sendSysex calls my generate
Jeff> method. When the call returns, SysexWidget.sendSysex
Jeff> calls setMessage(sysex, sysex.length). Because
Jeff> setMessage expects a valid sysex string and not a CC
Jeff> messages, it throws away the CC message and just
Jeff> returns the 0xF0 and 0xF7 sysex delimiters.

Does not SysexMessage.setMessage throw InvalidMidiDataException? It's
interesting.

Jeff> Are you suggesting adding something like the code
Jeff> snippet you sent to the SysexWidget.sendSysex method?
Jeff> 
Jeff> I suppose you could do something like check the first
Jeff> byte of the data and if it's equal to 0xF0, call
Jeff> setMessage, else have it continue through a case
Jeff> construct and test for the various other types of MIDI
Jeff> data. Is this what you're suggesting?

The method I sent you returns an array of MidiMessage (if it works as I
expect:-)). You can send each of them by using driver.send().

But as you see, the code which convert byte array into an array of MidiMessage
is very inefficient. Driver can easily send short messages without
using SysexSender by using one of Driver.send() methods now.
I started thinking that it might be better to fix drivers which use
SysexSender for non-sysex message. How did you list up the lots of
drivers of the kind?
-- 
Hiroo Hayashi



-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Jsynthlib-devel mailing list
Jsy...@li...
https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel

		
---------------------------------
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.

Re: [Jsynthlib-devel] Interfaces

[Hiroo H. <hir...@co...>]

Hi,

I've checked in the change for Patch factory.  Here is the summary of
the interface changes.

Patch
        static IDriver chooseDriver(byte[]) is added.
        static IPatch[] valueOf(byte[]) is added.
        static String getPatchHeader(byte[]) is added.

# It seems that valueOf() and getInstance are used for factory.  I used
# valueOf() for the factory method.

IPatch
        IPatch[] dissect() is removed.
        void trimSysex() is removed.

IDriver
        IPatch[] createPatch(byte[]) is added.
        boolean supportsPatch(String, IPatch) is removed.
        boolean supportsPatch(String, byte[]) is added.

IPatchDriver
        IPatch[] createPatch(byte[]) is removed.
        IPatch[] createPatch(SysexMessage[]) is added.
        void trimSysex(IPatch) is removed.

IConverter
        extractPatch() was removed.


I tried not to change the program behavior, but I might make a mistake. 
Let me know if you see anything.

Thanks.

On Sat, 21 Aug 2004 15:07:13 -0500
Hiroo Hayashi <hir...@co...> wrote:

Hiroo> Hi Rib,
Hiroo> 
Hiroo> On Sat, 21 Aug 2004 11:55:26 -0700
Hiroo> Rib Rdb <ri...@gm...> wrote:
Hiroo> 
Hiroo> Rib> > My next question would be why Converter still extended the Driver:-)
Hiroo> Rib> > The checksumming is the only reason?  Or did you see any other problems?
Hiroo> Rib> 
Hiroo> Rib> I didn't see any problems at the time, but I just thought of a problem
Hiroo> Rib> when I saw that you added dissect() to IPatch. If Converter is not an
Hiroo> Rib> IPatchDriver, so there would be no way for a Patch's driver to be a
Hiroo> Rib> converter.  I think instead we need to make dissect(byte[]) and
Hiroo> Rib> dissect(SysexMessage[]), or else make createPatch return IPatch[] and
Hiroo> Rib> move createPatch from IPatchDriver to IDriver.  What do you think?
Hiroo> 
Hiroo> I was thinking about the problem, too  Your mail made the problem clear. 
Hiroo> My take is almost the latter.
Hiroo> 
Hiroo> Let me explain what I'm thinking now.
Hiroo> 
Hiroo> IConverter is used by Patch.dissect() now.
Hiroo> 
Hiroo> IPatch.dissect() is called by ImportAllDialog.doImport(),
Hiroo> ImportMidiFile.doImport(), LibraryFrame.importPatch(),
Hiroo> SceneFrame.importPatch(), and SysexGetDialog.pasterInfoSelectedFrame().
Hiroo> 
Hiroo> The input data for SysexGetDialog.pasterInfoSelectedFrame() is
Hiroo> SysexMessage[] and driver is known.  What we need is
Hiroo> 
Hiroo>         IPatch[] IPatchDriver.createPatch(SysexMessage[])
Hiroo> 
Hiroo> The most of code in SysexGetDialog.pasterInfoSelectedFrame() will be
Hiroo> included in this method.
Hiroo> The current pasterInfoSelectedFrame() tries other device/drivers when
Hiroo> the received data is not expected one.  I think we should simply cause
Hiroo> error on this case.
Hiroo> 
Hiroo> The input data for ImportAllDialog.doImport(), ImportMidiFile.doImport(),
Hiroo> LibraryFrame.importPatch(), and SceneFrame.importPatch() is byte[] and
Hiroo> driver is unknown for them.  I think this is the job of patch factory
Hiroo> you wrote.
Hiroo> 
Hiroo>         static IPatch[] Patch.createPatch(byte[])
Hiroo> 
Hiroo> This static method will be used for any IPatch object.  Using Patch
Hiroo> class (an implementation of IPatch) may not be proper.  On the other
Hiroo> hand I feel it might be overkill to create a new class
Hiroo> (PatchFactory.java?) only for this, and I don't see a proper class which
Hiroo> will include this...
Hiroo> 
Hiroo> This method will use IDriver.supportsPatch(String, IPatch) (we may want
Hiroo> to change the second argument to byte[]) and the selected driver will
Hiroo> use IPatch[] IDriver.createPatch(byte[]) which you proposed.
Hiroo> 
Hiroo> And if we have IDriver.supportsPatch(String, byte[]), a Patch's driver
Hiroo> does not has to be a converter.
Hiroo> 
Hiroo> IPatch IPatchDriver.createPatch(byte[]) will be replaced by IPatch[]
Hiroo> IDriver.createPatch(byte[]).
Hiroo> 
Hiroo> IPatch.dissect() is no longer an interface method.
Hiroo> 
Hiroo> How do you think?  If you agree with me and don't mind, I'll try to make this
Hiroo> change during this weekend.
Hiroo> 
Hiroo> PS.
Hiroo> To make consistent with IPatch IPatchDriver.createPatch(byte[]), 
Hiroo> Patch IPatchDriver.createNewPatch() can be renamed to IPatch
Hiroo> IPatchDriver.createPatch().  Of course Patch Driver.createNewPatch()
Hiroo> will stay the same.
Hiroo> -- 
Hiroo> Hiroo Hayashi
Hiroo> 
Hiroo> 
Hiroo> 
Hiroo> -------------------------------------------------------
Hiroo> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
Hiroo> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Hiroo> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
Hiroo> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
Hiroo> _______________________________________________
Hiroo> Jsynthlib-devel mailing list
Hiroo> Jsy...@li...
Hiroo> https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel

-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] Sending CC Messages and Disabled Edit Menu

[Hiroo H. <hir...@co...>]

Jeff,

I assumed that SysexMessage[] MidiUtil.byteArrayToSysexMessages() was
used and I made a replacement for it.  Sorry for confusing you.

Jeff> I'm not sure I understand your message. I don't think
Jeff> the problem is in the SysexSender but rather in the
Jeff> SysexWidget.sendSysex method. To restate my original
Jeff> message, first SysexWidget.sendSysex calls my generate
Jeff> method. When the call returns, SysexWidget.sendSysex
Jeff> calls setMessage(sysex, sysex.length). Because
Jeff> setMessage expects a valid sysex string and not a CC
Jeff> messages, it throws away the CC message and just
Jeff> returns the 0xF0 and 0xF7 sysex delimiters.

Does not SysexMessage.setMessage throw InvalidMidiDataException?  It's
interesting.

Jeff> Are you suggesting adding something like the code
Jeff> snippet you sent to the SysexWidget.sendSysex method?
Jeff> 
Jeff> I suppose you could do something like check the first
Jeff> byte of the data and if it's equal to 0xF0, call
Jeff> setMessage, else have it continue through a case
Jeff> construct and test for the various other types of MIDI
Jeff> data. Is this what you're suggesting?

The method I sent you returns an array of MidiMessage (if it works as I
expect:-)).  You can send each of them by using driver.send().

But as you see, the code which convert byte array into an array of MidiMessage
is very inefficient.  Driver can easily send short messages without
using SysexSender by using one of Driver.send() methods now.
I started thinking that it might be better to fix drivers which use
SysexSender for non-sysex message.  How did you list up the lots of
drivers of the kind?
-- 
Hiroo Hayashi

Fwd: Fw: Re: [Jsynthlib-devel] Sending CC Messages and Disabled Edit Menu

[Jeff W. <jww...@ya...>]

Hiroo,

Greetings!!
I'm not sure I understand your message. I don't think
the problem is in the SysexSender but rather in the
SysexWidget.sendSysex method. To restate my original
message, first SysexWidget.sendSysex calls my generate
method. When the call returns, SysexWidget.sendSysex
calls setMessage(sysex, sysex.length). Because
setMessage expects a valid sysex string and not a CC
messages, it throws away the CC message and just
returns the 0xF0 and 0xF7 sysex delimiters.

Are you suggesting adding something like the code
snippet you sent to the SysexWidget.sendSysex method?

I suppose you could do something like check the first
byte of the data and if it's equal to 0xF0, call
setMessage, else have it continue through a case
construct and test for the various other types of MIDI
data. Is this what you're suggesting?

Jeff

--- Hiroo Hayashi <hir...@co...> wrote:

> From: Hiroo Hayashi <hir...@co...>
> To: JSynthLib Development
> <jsy...@li...>
> Subject: Fw: Re: [Jsynthlib-devel] Sending CC
> Messages and Disabled Edit Menu
> Date: Sun, 22 Aug 2004 21:56:45 -0500
> 
> I forgot to send mailing list.
> 
> Jeff, could you try the patch at the bottom of this
> mail?  I borrowed
> the code for LinuxMidiProvier which I made with
> Torsten.  Of course you
> need to change SysexSender also.
> 
> Forwarded by Hiroo Hayashi
> <hir...@co...>
> ----------------------- Original Message
> -----------------------
> From:    Hiroo Hayashi <hir...@co...>
> To:      Jeff Weber <jww...@ya...>
> Date:    Sun, 22 Aug 2004 20:04:24 -0500
> Subject: Re: [Jsynthlib-devel] Sending CC Messages
> and Disabled Edit Menu
> ----
> 
> Hi,
> 
> Jeff> Looking at other drivers that use subclasses
> of
> Jeff> SysexSender, I noticed that a lot of them send
> sysex
> Jeff> for this purpose. But this really isn't
> practical for
> Jeff> the Pods (the only other option is to send
> complete
> Jeff> sysex records and the Pods tend to choke if
> you send
> Jeff> too much data to quickly). If anyone's
> planning to
> Jeff> address this issue, I hope this helps.
> 
> This is known issue, but I thought it was not high
> priority.  I made
> this change in April and there was only one report
> for this issue.  (At
> that time I recommended to change driver to use
> SysexSend only for sysex
> message.) I misunderstand most of driver did not
> send Short message by
> using SysexSender.
> It was my laziness not to check all drivers.  I
> checked some drivers but
> I did not hit drivers who use SysexSend for Short
> Message.
> 
> I'll raise the priority for this.
> 
> Jeff> Also, I mentioned a couple of weeks ago a
> problem I
> Jeff> was having with version 0.19 where the Edit...
> command
> Jeff> was disabled when I select a patch in the
> library
> Jeff> window. I received a reply from Torsten saying
> he had
> Jeff> fixed the problem and that I should try the
> lastest
> Jeff> version. I've tried several new versions since
> then
> Jeff> and I'm still having the same problem. For the
> time
> Jeff> being I've had to temporarily wire the Play
> command to
> Jeff> bring up my editor (the Pods can't "Play"
> patches
> Jeff> anyway). So far I haven't been able to track
> down the
> Jeff> cause of the problem. I still have a couple of
> ideas I
> Jeff> haven't tried yet but if anyone has any
> insight into
> Jeff> this, I sure would appreciate hearing from
> you.
> 
> I cannot reproduce this.  Have you implemented
> editPatch as I replied
> you?
> -- 
> Hiroo Hayashi
> 
> --------------------- Original Message Ends
> --------------------
> Index: MidiUtil.java
>
===================================================================
> RCS file:
> /cvsroot/jsynthlib/JSynthLib/core/MidiUtil.java,v
> retrieving revision 1.17
> diff -u -r1.17 MidiUtil.java
> --- MidiUtil.java	22 Aug 2004 00:09:14 -0000	1.17
> +++ MidiUtil.java	23 Aug 2004 03:50:41 -0000
> @@ -23,6 +23,7 @@
>  
>  import java.io.File;
>  import javax.sound.midi.*;
> +
>  import java.util.*;
>  
>  /**
> @@ -954,4 +955,138 @@
>  	
>  	sequencer.start();
>      }
> +
> +    // create a separate class when jsynthlib.midi
> package is created.
> +    public static class ByteToMidiMessage  {
> +	private static int runningStatus;
> +	private static boolean thirdByte;
> +	private static byte[] buf;
> +	private static int size; // only for Sysex
> +	private static ArrayList list;
> +
> +	public static MidiMessage[] valueOf(byte[] sysex)
> {
> +	    runningStatus = 0;
> +	    thirdByte = false;
> +	    buf = new byte[sysex.length];
> +	    list = new ArrayList();
> +	    try {
> +                for (int i = 0; i < sysex.length;
> i++) {
> +                    addToList((int) (sysex[i] &
> 0xFF));
> +                }
> +            } catch (InvalidMidiDataException e) {
> +                ErrorMsg.reportStatus(e);
> +            }
> +	    return (MidiMessage[]) list.toArray(new
> MidiMessage[0]);
> +	}
> +
> +	private static void transmit(MidiMessage msg) {
> +	    list.add(msg);
> +	}
> +
> +	/**
> +	 * convert a MIDI byte stream into MidiMessage
> objects
> +	 * and add them to input list, <code>list</code>.
> +	 *
> +	 * @author Hiroo Hayashi
> +	 * @see "MIDI 1.0 Detailed Specification, Page
> A-3"
> +	 * @See javax.sound.midi.SystemMessage
> +	 */
> +	private static void addToList(int c) throws
> InvalidMidiDataException {
> +	    MidiMessage msg;
> +	    if ((c & ~0xff) != 0)
> +		throw new InvalidMidiDataException();
> +	    if ((c & 0x80) == 0x80) {
> +		// status byte
> +		if ((c & 0xf8) == 0xf8) { // System Real Time
> Message
> +		    // 0 byte message
> +		    msg = (MidiMessage) new ShortMessage();
> +		    ((ShortMessage) msg).setMessage(c);
> +		    transmit(msg);
> +		} else {
> +		    thirdByte = false;
> +		    switch (c) {
> +		    case ShortMessage.END_OF_EXCLUSIVE:
> +			if (runningStatus ==
> SysexMessage.SYSTEM_EXCLUSIVE) {
> +			    byte[] d = new byte[size + 1];
> +			    System.arraycopy(buf, 0, d, 0, size);
> +			    d[size++] = (byte) c;
> +			    msg = (MidiMessage) new SysexMessage();
> +			    ((SysexMessage) msg).setMessage(d, size);
> +			    transmit(msg);
> +			}
> +			break;
> +		    case ShortMessage.TUNE_REQUEST: // 0xf6
> +			// 0 byte message
> +			msg = (MidiMessage) new ShortMessage();
> +			((ShortMessage) msg).setMessage(c);
> +			transmit(msg);
> +			break;
> +		    case SysexMessage.SYSTEM_EXCLUSIVE:
> +			size = 1;
> +			// FALLTHROUGH
> +		    default:
> +			buf[0] = (byte) c;
> +		    }
> +		    runningStatus = c;
> +		}
> +	    } else {
> +		// data byte
> +		if (thirdByte) {
> +		    thirdByte = false;
> +		    msg = (MidiMessage) new ShortMessage();
> +		    ((ShortMessage) msg).setMessage((int) (buf[0]
> & 0xff),
> +						    (int) (buf[1] & 0xff), c);
> +		    transmit(msg);
> +		} else {
> +		    switch (runningStatus < 0xf0 ? runningStatus
> & 0xf0 : runningStatus) {
> +		    case ShortMessage.SONG_POSITION_POINTER: //
> 0xf2
> +			// 2 byte message
> +			runningStatus = 0;
> +			// FALLTHROUGH
> +		    case ShortMessage.NOTE_OFF:		// 0x8n
> +		    case ShortMessage.NOTE_ON:		// 0x9n
> +		    case ShortMessage.POLY_PRESSURE:	// 0xAn
> +		    case ShortMessage.CONTROL_CHANGE:	// 0xBn
> +		    case ShortMessage.PITCH_BEND:	// 0xEn
> +			// 2 byte message
> +			thirdByte = true;
> +			buf[1] = (byte) c;
> +			break;
> +
> +		    case ShortMessage.MIDI_TIME_CODE:	// 0xf1
> +		    case ShortMessage.SONG_SELECT:	// 0xf3
> +			// 1 byte message
> +			runningStatus = 0;
> +			// FALLTHROUGH
> +		    case ShortMessage.PROGRAM_CHANGE:	// 0xCn
> +		    case ShortMessage.CHANNEL_PRESSURE:	// 0xDn
> +			// 1 byte message
> +			msg = (MidiMessage) new ShortMessage();
> +			((ShortMessage) msg).setMessage((int) (buf[0] &
> 0xff), c, 0);
> +			transmit(msg);
> +			break;
> +
> +		    case SysexMessage.SYSTEM_EXCLUSIVE:	// 0xf0
> +			buf[size++] = (byte) c;
> +			if (size == buf.length) {
> +			    // Sysex data buffer is full
> +			    byte[] d = new byte[size];
> +			    System.arraycopy(buf, 0, d, 0, size);
> +			    msg = (MidiMessage) new SysexMessage();
> +			    ((SysexMessage) msg).setMessage(d, size);
> +			    transmit(msg);
> +			    // See SysexMessage document.
> +			    buf[0] = (byte)
> SysexMessage.SPECIAL_SYSTEM_EXCLUSIVE;
> +			    size = 1;
> +			}
> +			break;
> +
> +		    default: // 0, 0xf4 (undef), 0xf5 (undef),
> 0xf6 (Tune Request), 0xf7 (EOX)
> +			runningStatus = 0;
> +			// ignore data
> +		    }
> +		}
> +	    }
> +	}
> +    }
>  } // MidiUtil
> 
> 
> 
>
-------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest
> price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R
> for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping
> and Free Gift.
>
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Jsynthlib-devel mailing list
> Jsy...@li...
>
https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
> 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Fwd: Re: [Jsynthlib-devel] Sending CC Messages and Disabled Edit Menu

[Jeff W. <jww...@ya...>]

Hey, I've got my Edit... menu back!!!

I tried what Rib Rdb suggested and it does bring the
edit menu back. But then I asked myself why none of
the other drivers override hasEditor. When I looked at
Driver.hasEditor I realized what the problem was.

I had my editPatch method coded as editPatch(IPatch)
instead of editPatch(Patch). This caused
Driver.hasEditor to return false, since it was looking
for a editPatch(Patch). All I had to do to solve the
problem was change my editPatch(IPatch) to
editPatch(Patch). I could then remove the override of
hasEditor and everything worked as it should.

Thanks Rib Rdb, for your help!!!

--- Rib Rdb <ri...@gm...> wrote:

> Date: Sun, 22 Aug 2004 20:04:11 -0700
> From: Rib Rdb <ri...@gm...>
> To: Jeff Weber <jww...@ya...>
> Subject: Re: [Jsynthlib-devel] Sending CC Messages
> and Disabled Edit Menu
> 
> Try overriding hasEditor to return true.
> 
> On Sun, 22 Aug 2004 18:24:20 -0700 (PDT), Jeff Weber
> <jww...@ya...> wrote:
> > I use a number of subclasses of SysexSender in my
> > editors to send CC messages to the Pod and Bass
> Pod.
> > This worked fine in verision 0.18 but ever since I
> > started working in version 0.19 it just sends a
> series
> > of empty sysex messages (0xF0 0xF7). I'm
> developing on
> > a Mac and I used a program called MIDI Monitor to
> > verify this.
> > 
> > This weekend I finally got time to sit down with a
> > debugger and try to figure out the problem. I
> found
> > that the generate method of my SysexSender
> sublclass
> > is being called by the SysexWidget.sendSysex
> method.
> > When the call returns from my generate method, it
> > calls setMessage(sysex, sysex.length). It looks
> like
> > setMessage expects a valid sysex string, complete
> with
> > 0xF0 and 0xF7 delimiters. Apparently, if
> setMessage
> > sees anything else, for example a CC message, it
> just
> > says, nope, this isn't valid sysex so I'm just
> going
> > to send 0xF0 0xF7.
> > 
> > Looking at other drivers that use subclasses of
> > SysexSender, I noticed that a lot of them send
> sysex
> > for this purpose. But this really isn't practical
> for
> > the Pods (the only other option is to send
> complete
> > sysex records and the Pods tend to choke if you
> send
> > too much data to quickly). If anyone's planning to
> > address this issue, I hope this helps.
> > 
> > Also, I mentioned a couple of weeks ago a problem
> I
> > was having with version 0.19 where the Edit...
> command
> > was disabled when I select a patch in the library
> > window. I received a reply from Torsten saying he
> had
> > fixed the problem and that I should try the
> lastest
> > version. I've tried several new versions since
> then
> > and I'm still having the same problem. For the
> time
> > being I've had to temporarily wire the Play
> command to
> > bring up my editor (the Pods can't "Play" patches
> > anyway). So far I haven't been able to track down
> the
> > cause of the problem. I still have a couple of
> ideas I
> > haven't tried yet but if anyone has any insight
> into
> > this, I sure would appreciate hearing from you.
> > 
> > Thanks,
> > Jeff
> > 
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Mail is new and improved - Check it out!
> > http://promotions.yahoo.com/new_mail
> > 
> >
>
-------------------------------------------------------
> > SF.Net email is sponsored by Shop4tech.com-Lowest
> price on Blank Media
> > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic
> DVD+R for only $33
> > Save 50% off Retail on Ink & Toner - Free Shipping
> and Free Gift.
> >
>
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> > _______________________________________________
> > Jsynthlib-devel mailing list
> > Jsy...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
> >
> 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Fw: Re: [Jsynthlib-devel] Sending CC Messages and Disabled Edit Menu

[Hiroo H. <hir...@co...>]

I forgot to send mailing list.

Jeff, could you try the patch at the bottom of this mail?  I borrowed
the code for LinuxMidiProvier which I made with Torsten.  Of course you
need to change SysexSender also.

Forwarded by Hiroo Hayashi <hir...@co...>
----------------------- Original Message -----------------------
From:    Hiroo Hayashi <hir...@co...>
To:      Jeff Weber <jww...@ya...>
Date:    Sun, 22 Aug 2004 20:04:24 -0500
Subject: Re: [Jsynthlib-devel] Sending CC Messages and Disabled Edit Menu
----

Hi,

Jeff> Looking at other drivers that use subclasses of
Jeff> SysexSender, I noticed that a lot of them send sysex
Jeff> for this purpose. But this really isn't practical for
Jeff> the Pods (the only other option is to send complete
Jeff> sysex records and the Pods tend to choke if you send
Jeff> too much data to quickly). If anyone's planning to
Jeff> address this issue, I hope this helps.

This is known issue, but I thought it was not high priority.  I made
this change in April and there was only one report for this issue.  (At
that time I recommended to change driver to use SysexSend only for sysex
message.) I misunderstand most of driver did not send Short message by
using SysexSender.
It was my laziness not to check all drivers.  I checked some drivers but
I did not hit drivers who use SysexSend for Short Message.

I'll raise the priority for this.

Jeff> Also, I mentioned a couple of weeks ago a problem I
Jeff> was having with version 0.19 where the Edit... command
Jeff> was disabled when I select a patch in the library
Jeff> window. I received a reply from Torsten saying he had
Jeff> fixed the problem and that I should try the lastest
Jeff> version. I've tried several new versions since then
Jeff> and I'm still having the same problem. For the time
Jeff> being I've had to temporarily wire the Play command to
Jeff> bring up my editor (the Pods can't "Play" patches
Jeff> anyway). So far I haven't been able to track down the
Jeff> cause of the problem. I still have a couple of ideas I
Jeff> haven't tried yet but if anyone has any insight into
Jeff> this, I sure would appreciate hearing from you.

I cannot reproduce this.  Have you implemented editPatch as I replied
you?
-- 
Hiroo Hayashi

--------------------- Original Message Ends --------------------
Index: MidiUtil.java
===================================================================
RCS file: /cvsroot/jsynthlib/JSynthLib/core/MidiUtil.java,v
retrieving revision 1.17
diff -u -r1.17 MidiUtil.java
--- MidiUtil.java	22 Aug 2004 00:09:14 -0000	1.17
+++ MidiUtil.java	23 Aug 2004 03:50:41 -0000
@@ -23,6 +23,7 @@
 
 import java.io.File;
 import javax.sound.midi.*;
+
 import java.util.*;
 
 /**
@@ -954,4 +955,138 @@
 	
 	sequencer.start();
     }
+
+    // create a separate class when jsynthlib.midi package is created.
+    public static class ByteToMidiMessage  {
+	private static int runningStatus;
+	private static boolean thirdByte;
+	private static byte[] buf;
+	private static int size; // only for Sysex
+	private static ArrayList list;
+
+	public static MidiMessage[] valueOf(byte[] sysex) {
+	    runningStatus = 0;
+	    thirdByte = false;
+	    buf = new byte[sysex.length];
+	    list = new ArrayList();
+	    try {
+                for (int i = 0; i < sysex.length; i++) {
+                    addToList((int) (sysex[i] & 0xFF));
+                }
+            } catch (InvalidMidiDataException e) {
+                ErrorMsg.reportStatus(e);
+            }
+	    return (MidiMessage[]) list.toArray(new MidiMessage[0]);
+	}
+
+	private static void transmit(MidiMessage msg) {
+	    list.add(msg);
+	}
+
+	/**
+	 * convert a MIDI byte stream into MidiMessage objects
+	 * and add them to input list, <code>list</code>.
+	 *
+	 * @author Hiroo Hayashi
+	 * @see "MIDI 1.0 Detailed Specification, Page A-3"
+	 * @See javax.sound.midi.SystemMessage
+	 */
+	private static void addToList(int c) throws InvalidMidiDataException {
+	    MidiMessage msg;
+	    if ((c & ~0xff) != 0)
+		throw new InvalidMidiDataException();
+	    if ((c & 0x80) == 0x80) {
+		// status byte
+		if ((c & 0xf8) == 0xf8) { // System Real Time Message
+		    // 0 byte message
+		    msg = (MidiMessage) new ShortMessage();
+		    ((ShortMessage) msg).setMessage(c);
+		    transmit(msg);
+		} else {
+		    thirdByte = false;
+		    switch (c) {
+		    case ShortMessage.END_OF_EXCLUSIVE:
+			if (runningStatus == SysexMessage.SYSTEM_EXCLUSIVE) {
+			    byte[] d = new byte[size + 1];
+			    System.arraycopy(buf, 0, d, 0, size);
+			    d[size++] = (byte) c;
+			    msg = (MidiMessage) new SysexMessage();
+			    ((SysexMessage) msg).setMessage(d, size);
+			    transmit(msg);
+			}
+			break;
+		    case ShortMessage.TUNE_REQUEST: // 0xf6
+			// 0 byte message
+			msg = (MidiMessage) new ShortMessage();
+			((ShortMessage) msg).setMessage(c);
+			transmit(msg);
+			break;
+		    case SysexMessage.SYSTEM_EXCLUSIVE:
+			size = 1;
+			// FALLTHROUGH
+		    default:
+			buf[0] = (byte) c;
+		    }
+		    runningStatus = c;
+		}
+	    } else {
+		// data byte
+		if (thirdByte) {
+		    thirdByte = false;
+		    msg = (MidiMessage) new ShortMessage();
+		    ((ShortMessage) msg).setMessage((int) (buf[0] & 0xff),
+						    (int) (buf[1] & 0xff), c);
+		    transmit(msg);
+		} else {
+		    switch (runningStatus < 0xf0 ? runningStatus & 0xf0 : runningStatus) {
+		    case ShortMessage.SONG_POSITION_POINTER: // 0xf2
+			// 2 byte message
+			runningStatus = 0;
+			// FALLTHROUGH
+		    case ShortMessage.NOTE_OFF:		// 0x8n
+		    case ShortMessage.NOTE_ON:		// 0x9n
+		    case ShortMessage.POLY_PRESSURE:	// 0xAn
+		    case ShortMessage.CONTROL_CHANGE:	// 0xBn
+		    case ShortMessage.PITCH_BEND:	// 0xEn
+			// 2 byte message
+			thirdByte = true;
+			buf[1] = (byte) c;
+			break;
+
+		    case ShortMessage.MIDI_TIME_CODE:	// 0xf1
+		    case ShortMessage.SONG_SELECT:	// 0xf3
+			// 1 byte message
+			runningStatus = 0;
+			// FALLTHROUGH
+		    case ShortMessage.PROGRAM_CHANGE:	// 0xCn
+		    case ShortMessage.CHANNEL_PRESSURE:	// 0xDn
+			// 1 byte message
+			msg = (MidiMessage) new ShortMessage();
+			((ShortMessage) msg).setMessage((int) (buf[0] & 0xff), c, 0);
+			transmit(msg);
+			break;
+
+		    case SysexMessage.SYSTEM_EXCLUSIVE:	// 0xf0
+			buf[size++] = (byte) c;
+			if (size == buf.length) {
+			    // Sysex data buffer is full
+			    byte[] d = new byte[size];
+			    System.arraycopy(buf, 0, d, 0, size);
+			    msg = (MidiMessage) new SysexMessage();
+			    ((SysexMessage) msg).setMessage(d, size);
+			    transmit(msg);
+			    // See SysexMessage document.
+			    buf[0] = (byte) SysexMessage.SPECIAL_SYSTEM_EXCLUSIVE;
+			    size = 1;
+			}
+			break;
+
+		    default: // 0, 0xf4 (undef), 0xf5 (undef), 0xf6 (Tune Request), 0xf7 (EOX)
+			runningStatus = 0;
+			// ignore data
+		    }
+		}
+	    }
+	}
+    }
 } // MidiUtil

[Jsynthlib-devel] Sending CC Messages and Disabled Edit Menu

[Jeff W. <jww...@ya...>]

I use a number of subclasses of SysexSender in my
editors to send CC messages to the Pod and Bass Pod.
This worked fine in verision 0.18 but ever since I
started working in version 0.19 it just sends a series
of empty sysex messages (0xF0 0xF7). I'm developing on
a Mac and I used a program called MIDI Monitor to
verify this.

This weekend I finally got time to sit down with a
debugger and try to figure out the problem. I found
that the generate method of my SysexSender sublclass
is being called by the SysexWidget.sendSysex method.
When the call returns from my generate method, it
calls setMessage(sysex, sysex.length). It looks like
setMessage expects a valid sysex string, complete with
0xF0 and 0xF7 delimiters. Apparently, if setMessage
sees anything else, for example a CC message, it just
says, nope, this isn't valid sysex so I'm just going
to send 0xF0 0xF7.

Looking at other drivers that use subclasses of
SysexSender, I noticed that a lot of them send sysex
for this purpose. But this really isn't practical for
the Pods (the only other option is to send complete
sysex records and the Pods tend to choke if you send
too much data to quickly). If anyone's planning to
address this issue, I hope this helps.

Also, I mentioned a couple of weeks ago a problem I
was having with version 0.19 where the Edit... command
was disabled when I select a patch in the library
window. I received a reply from Torsten saying he had
fixed the problem and that I should try the lastest
version. I've tried several new versions since then
and I'm still having the same problem. For the time
being I've had to temporarily wire the Play command to
bring up my editor (the Pods can't "Play" patches
anyway). So far I haven't been able to track down the
cause of the problem. I still have a couple of ideas I
haven't tried yet but if anyone has any insight into
this, I sure would appreciate hearing from you.

Thanks,
Jeff


		
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

Re: [Jsynthlib-devel] Interfaces

[Hiroo H. <hir...@co...>]

Hi Rib,

On Sat, 21 Aug 2004 11:55:26 -0700
Rib Rdb <ri...@gm...> wrote:

Rib> > My next question would be why Converter still extended the Driver:-)
Rib> > The checksumming is the only reason?  Or did you see any other problems?
Rib> 
Rib> I didn't see any problems at the time, but I just thought of a problem
Rib> when I saw that you added dissect() to IPatch. If Converter is not an
Rib> IPatchDriver, so there would be no way for a Patch's driver to be a
Rib> converter.  I think instead we need to make dissect(byte[]) and
Rib> dissect(SysexMessage[]), or else make createPatch return IPatch[] and
Rib> move createPatch from IPatchDriver to IDriver.  What do you think?

I was thinking about the problem, too  Your mail made the problem clear. 
My take is almost the latter.

Let me explain what I'm thinking now.

IConverter is used by Patch.dissect() now.

IPatch.dissect() is called by ImportAllDialog.doImport(),
ImportMidiFile.doImport(), LibraryFrame.importPatch(),
SceneFrame.importPatch(), and SysexGetDialog.pasterInfoSelectedFrame().

The input data for SysexGetDialog.pasterInfoSelectedFrame() is
SysexMessage[] and driver is known.  What we need is

        IPatch[] IPatchDriver.createPatch(SysexMessage[])

The most of code in SysexGetDialog.pasterInfoSelectedFrame() will be
included in this method.
The current pasterInfoSelectedFrame() tries other device/drivers when
the received data is not expected one.  I think we should simply cause
error on this case.

The input data for ImportAllDialog.doImport(), ImportMidiFile.doImport(),
LibraryFrame.importPatch(), and SceneFrame.importPatch() is byte[] and
driver is unknown for them.  I think this is the job of patch factory
you wrote.

        static IPatch[] Patch.createPatch(byte[])

This static method will be used for any IPatch object.  Using Patch
class (an implementation of IPatch) may not be proper.  On the other
hand I feel it might be overkill to create a new class
(PatchFactory.java?) only for this, and I don't see a proper class which
will include this...

This method will use IDriver.supportsPatch(String, IPatch) (we may want
to change the second argument to byte[]) and the selected driver will
use IPatch[] IDriver.createPatch(byte[]) which you proposed.

And if we have IDriver.supportsPatch(String, byte[]), a Patch's driver
does not has to be a converter.

IPatch IPatchDriver.createPatch(byte[]) will be replaced by IPatch[]
IDriver.createPatch(byte[]).

IPatch.dissect() is no longer an interface method.

How do you think?  If you agree with me and don't mind, I'll try to make this
change during this weekend.

PS.
To make consistent with IPatch IPatchDriver.createPatch(byte[]), 
Patch IPatchDriver.createNewPatch() can be renamed to IPatch
IPatchDriver.createPatch().  Of course Patch Driver.createNewPatch()
will stay the same.
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] Interfaces

[Hiroo H. <hir...@co...>]

After taking look at the latest code, I've concluded that I was wrong. 
I wrote I won't need IConverter interface.  But it's much better to have
IConverter interface.

It's in head.

On Mon, 16 Aug 2004 07:18:20 -0500
Hiroo Hayashi <hir...@co...> wrote:

Hiroo> My next question would be why Converter still extended the Driver:-)
Hiroo> The checksumming is the only reason?  Or did you see any other problems?
Hiroo> 
Hiroo> On Sun, 15 Aug 2004 22:34:20 -0700
Hiroo> Rib Rdb <ri...@gm...> wrote:
Hiroo> 
Hiroo> Rib> Actually I made the public static one because I had originally made
Hiroo> Rib> Converter just implement IDriver instead of extending Driver, and it
Hiroo> Rib> needed to do checksumming.  But then I decided to leave Converter the
Hiroo> Rib> way it was, so I don't think the CalculateChecksum method is needed.
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] Interfaces

[Hiroo H. <hir...@co...>]

I've made calculateChecksum(Patch, int, int, int) static.  It's in head.

Thanks.

On Mon, 16 Aug 2004 07:18:20 -0500
Hiroo Hayashi <hir...@co...> wrote:

Hiroo> Rib,
Hiroo>=20
Hiroo> My baseline is that calculateChecksum(Patch, int, int, int) should b=
e
Hiroo> static.
Hiroo>=20
Hiroo> My next question would be why Converter still extended the Driver:-)
Hiroo> The checksumming is the only reason?  Or did you see any other probl=
ems?
Hiroo>=20
Hiroo> On Sun, 15 Aug 2004 22:34:20 -0700
Hiroo> Rib Rdb <ri...@gm...> wrote:
Hiroo>=20
Hiroo> Rib> Actually I made the public static one because I had originally =
made
Hiroo> Rib> Converter just implement IDriver instead of extending Driver, a=
nd it
Hiroo> Rib> needed to do checksumming.  But then I decided to leave Convert=
er the
Hiroo> Rib> way it was, so I don't think the CalculateChecksum method is ne=
eded.
Hiroo> Rib>=20
Hiroo> Rib> On Sun, 15 Aug 2004 21:49:15 -0500, Hiroo Hayashi
Hiroo> Rib> <hir...@co...> wrote:
Hiroo> Rib> > Hi,
Hiroo> Rib> >=20
Hiroo> Rib> > Rib> Ok. I commited the interfaces. Eclipse gave some kind of=
 error when
Hiroo> Rib> > Rib> commiting, but it looks like it sent everything.  Let me=
 know if it
Hiroo> Rib> > Rib> did miss anything though.
Hiroo> Rib> >=20
Hiroo> Rib> > Your quick job always impresses me.
Hiroo> Rib> >=20
Hiroo> Rib> > I don't see any major problem.
Hiroo> Rib> >=20
Hiroo> Rib> > I've made the following change.
=2E..
Hiroo> Rib> > I'm seeing the following code in Driver.java.
Hiroo> Rib> >=20
Hiroo> Rib> >     protected void calculateChecksum(Patch patch, int start, =
int end, int ofs) {
Hiroo> Rib> >         CalculateChecksum(patch, start, end, ofs);
Hiroo> Rib> >     }
Hiroo> Rib> >=20
Hiroo> Rib> >     public final static void CalculateChecksum(Patch p, int s=
tart, int end, int ofs) {
Hiroo> Rib> >         ... // real code
Hiroo> Rib> >     }
Hiroo> Rib> >=20
Hiroo> Rib> > My take is to have only one method;
Hiroo> Rib> >     public static void calculateChecksum(Patch patch, int sta=
rt, int end,
Hiroo> Rib> >     int ofs)
Hiroo> Rib> >=20
Hiroo> Rib> > I understand you did not do this, because this broke synthdri=
ver
Hiroo> Rib> > compatibility.  But I think it is worth to be changed.  Any c=
omments?
Hiroo>=20
Hiroo> --=20
Hiroo> Hiroo Hayashi
--=20
Hiroo Hayashi

Re: [Jsynthlib-devel] patch editors

[Hiroo H. <hir...@co...>]

On Sun, 15 Aug 2004 22:44:40 -0700
Rib Rdb <ri...@gm...> wrote:

Rib> > BTW there are many lines like 'patch.getDriver().xxxxx(patch)'.  They can
Rib> > be 'patch.xxxxx()' by defining some one line methods in IPatch.  May I
Rib> > make the change?
Rib> 
Rib> Please do.

It's in head now.
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] patch editors

[<tt_...@gm...>]

Hi Ryan,

Rib Rdb wrote:
> As I was making that last commit I started thinking about patch
> editors, and I had the idea to move the hasEditor and editPatch
> functions from IPatchDriver to IPatch. We could easily put a method in
> Patch to maintain compatibility with existing drivers.  The advantage
> I see is that when you create an xml based editor, you can simply say
> what patch type it supports.  Then when you click to edit a patch, it
> could give you a list of possible editors, or if there's only one open
> it right away.  How does this sound?

This sounds good to me.
Generally I like the idea to move all methods from the drivers which are not concerning the interaction with a synth.
Like the editing of patches as you're proposing.

Bye
Torsten

Re: [Jsynthlib-devel] patch editors

[Hiroo H. <hir...@co...>]

On Sun, 15 Aug 2004 22:44:40 -0700
Rib Rdb <ri...@gm...> wrote:

Rib> Hi.  I'm pretty good ad being confusing.  Let me try again.
Rib> 
Rib> On Sun, 15 Aug 2004 20:13:01 -0500, Hiroo Hayashi
Rib> <hir...@co...> wrote:
Rib> > 
Rib> > Rib> As I was making that last commit I started thinking about patch
Rib> > Rib> editors, and I had the idea to move the hasEditor and editPatch
Rib> > Rib> functions from IPatchDriver to IPatch. We could easily put a method in
Rib> > Rib> Patch to maintain compatibility with existing drivers.  The advantage
Rib> > Rib> I see is that when you create an xml based editor, you can simply say
Rib> > Rib> what patch type it supports.  Then when you click to edit a patch, it
Rib> > Rib> could give you a list of possible editors, or if there's only one open
Rib> > Rib> it right away.  How does this sound?
Rib> > 
Rib> > First I thought you were proposing 'IPatch.editPatch()', but it seems
Rib> > you were not.  Could you give me an example which would help me
Rib> > to understand.
Rib> 
Rib> That's exactly what I mean (well, I was thinking IPatch.edit() since
Rib> two Patches is redundant).   What I was trying to explain is that this
Rib> would make it easier to allow multiple editors for a given patch type
Rib> as we discussed before.

My thought was simply to define the following method in Patch.java;
        JSLFrame editPatch(Patch p) { // should be 'edit'
            return driver.editPatch(this);
        }

But I understood you were thinking more.

Rib> > BTW there are many lines like 'patch.getDriver().xxxxx(patch)'.  They can
Rib> > be 'patch.xxxxx()' by defining some one line methods in IPatch.  May I
Rib> > make the change?
Rib> 
Rib> Please do.

OK, I'll do.
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] Interfaces

[Hiroo H. <hir...@co...>]

Rib,

My baseline is that calculateChecksum(Patch, int, int, int) should be
static.

My next question would be why Converter still extended the Driver:-)
The checksumming is the only reason?  Or did you see any other problems?

On Sun, 15 Aug 2004 22:34:20 -0700
Rib Rdb <ri...@gm...> wrote:

Rib> Actually I made the public static one because I had originally made
Rib> Converter just implement IDriver instead of extending Driver, and it
Rib> needed to do checksumming.  But then I decided to leave Converter the
Rib> way it was, so I don't think the CalculateChecksum method is needed.
Rib> 
Rib> On Sun, 15 Aug 2004 21:49:15 -0500, Hiroo Hayashi
Rib> <hir...@co...> wrote:
Rib> > Hi,
Rib> > 
Rib> > Rib> Ok. I commited the interfaces. Eclipse gave some kind of error when
Rib> > Rib> commiting, but it looks like it sent everything.  Let me know if it
Rib> > Rib> did miss anything though.
Rib> > 
Rib> > Your quick job always impresses me.
Rib> > 
Rib> > I don't see any major problem.
Rib> > 
Rib> > I've made the following change.
Rib> > 
Rib> > 1. I updated the javadoc of new interfaces in core.
Rib> > 2. I replaced IPatchDriver.send(byte[]) with
Rib> > IPatchDriver.send(MidiMessage).
Rib> > 3. I reduced IPatchDriver reference in synthdrivers/*/*.
Rib> > 
Rib> > I'm seeing the following code in Driver.java.
Rib> > 
Rib> >     protected void calculateChecksum(Patch patch, int start, int end, int ofs) {
Rib> >         CalculateChecksum(patch, start, end, ofs);
Rib> >     }
Rib> > 
Rib> >     public final static void CalculateChecksum(Patch p, int start, int end, int ofs) {
Rib> >         ... // real code
Rib> >     }
Rib> > 
Rib> > My take is to have only one method;
Rib> >     public static void calculateChecksum(Patch patch, int start, int end,
Rib> >     int ofs)
Rib> > 
Rib> > I understand you did not do this, because this broke synthdriver
Rib> > compatibility.  But I think it is worth to be changed.  Any comments?

-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] Interfaces

[Hiroo H. <hir...@co...>]

Hi,
        
Rib> Ok. I commited the interfaces. Eclipse gave some kind of error when
Rib> commiting, but it looks like it sent everything.  Let me know if it
Rib> did miss anything though.

Your quick job always impresses me.

I don't see any major problem.

I've made the following change.

1. I updated the javadoc of new interfaces in core.
2. I replaced IPatchDriver.send(byte[]) with
IPatchDriver.send(MidiMessage).
3. I reduced IPatchDriver reference in synthdrivers/*/*.

I'm seeing the following code in Driver.java.

    protected void calculateChecksum(Patch patch, int start, int end, int ofs) {
        CalculateChecksum(patch, start, end, ofs);
    }
    
    public final static void CalculateChecksum(Patch p, int start, int end, int ofs) {
        ... // real code
    }

My take is to have only one method;
    public static void calculateChecksum(Patch patch, int start, int end,
    int ofs)

I understand you did not do this, because this broke synthdriver
compatibility.  But I think it is worth to be changed.  Any comments?
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] patch editors

[Hiroo H. <hir...@co...>]

Rib> As I was making that last commit I started thinking about patch
Rib> editors, and I had the idea to move the hasEditor and editPatch
Rib> functions from IPatchDriver to IPatch. We could easily put a method in
Rib> Patch to maintain compatibility with existing drivers.  The advantage
Rib> I see is that when you create an xml based editor, you can simply say
Rib> what patch type it supports.  Then when you click to edit a patch, it
Rib> could give you a list of possible editors, or if there's only one open
Rib> it right away.  How does this sound?

First I thought you were proposing 'IPatch.editPatch()', but it seems
you were not.  Could you give me an example which would help me
to understand.

BTW there are many lines like 'patch.getDriver().xxxxx(patch)'.  They can
be 'patch.xxxxx()' by defining some one line methods in IPatch.  May I
make the change?
-- 
Hiroo Hayashi

[Jsynthlib-devel] patch editors

[Rib R. <ri...@gm...>]

As I was making that last commit I started thinking about patch
editors, and I had the idea to move the hasEditor and editPatch
functions from IPatchDriver to IPatch. We could easily put a method in
Patch to maintain compatibility with existing drivers.  The advantage
I see is that when you create an xml based editor, you can simply say
what patch type it supports.  Then when you click to edit a patch, it
could give you a list of possible editors, or if there's only one open
it right away.  How does this sound?

sysex dispatcher )Re: [Jsynthlib-devel] Re: [jsynthlib-dev] Commit)

[Hiroo H. <hir...@co...>]

Rib,

If I understand correctly you mentioned about the case where
corresponding driver class is unknown.  In other words the case where 'new
Patch(byte[])' has been used.  I agree with you that we need a new
class/method to create a proper IPatch object.  Neither a class
implementing IPatch or a driver class cannot do the job.

But on this SysexGetDialog case, the driver class is known.  I think
driver class needs a new method which creates a IPatch object which the
driver uses.

Rib> This is why I was talking about some sort of sysex dispatcher class
Rib> that would take one or more messages, find which driver supports them,
Rib> then pass the messages to it.  The driver would create pne pr more
Rib> patches either store them in the dispatcher class, or maybe in a
Rib> patchbasket that was passed to the dispatcher.  I think we need to do
Rib> it this way instead of using a method to work with patches composed of
Rib> multiple messages.
=2E..
Rib> > But what shall we do for the line 165 of SysexGetDialog.java.
Rib> >=20
Rib> >     Patch p =3D new Patch(patchSysex, driver);
Rib> >=20
Rib> > I think we need IPatchDriver.newPatch(byte[]) method.
Rib> >=20
Rib> > # IPatchDriver is the interface for single patch driver and bank pat=
ch
Rib> > # driver.
Rib> >=20
Rib> > By introducing IPatch interface, a driver can have its own patch
Rib> > class.  To enjoy the merit, we will need
Rib> > IPatchDriver.newPatch(byte[]).
Rib> >=20
Rib> > Any comments? > all
Rib> > --
Rib> > Hiroo Hayashi
--=20
Hiroo Hayashi

Re: [Jsynthlib-devel] Interfaces

[Hiroo H. <hir...@co...>]

Rib,

Rib> I guess we need to choose the packages where the support files for xml
Rib> drivers, the drivers written in xml, and the ruby support classes
Rib> should go.
Rib> 
Rib> For easy reference, my original recomendation for these were,
Rib> respectively, org.jsynthlib.jsynthlib.core.xml,
Rib> org.jsynthlib.jsynthlib.xmldrivers, and org.jsynthlib.ruby.
Rib> 
Rib> I believe that Hiroo suggested org.jsynthlib.jsynthlib.xml and
Rib> org.jsynthlib.jsynthlib.drivers.
Rib> 
Rib> I'd be fine with having xml under jsynthlib instead of core, but I
Rib> wondered if it might be confused with the actual drivers written in
Rib> xml.  I recommended a separate directory for different types of
Rib> drivers because the parser can't tell the difference between a java
Rib> file and a messed up xml file.  But I suppose I could easily solve
Rib> this by requiring xml drivers to have a common extension (.xml,
Rib> .device, or .driver come to mind as possibilities).

Yes. Actually DeviceListWriter finds device classes by using filename
'synthdrivers/*/*Device.class' now.  (This is the only rule of class
name for synth drivers.)  We can do same thing for XML drivers.  I think
putting all synth driver in one place would have some more benefits.

Rib> > I'll stop changing core files for a while not to create conflict with
Rib> > you.  Are there anything I can help you for the interface change?
Rib> 
Rib> It'll probably be easier if I do it all myself.  I'll try to do it today.

OK.  Happy hacking!
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] Interfaces

[Rib R. <ri...@gm...>]

I guess we need to choose the packages where the support files for xml
drivers, the drivers written in xml, and the ruby support classes
should go.

For easy reference, my original recomendation for these were,
respectively, org.jsynthlib.jsynthlib.core.xml,
org.jsynthlib.jsynthlib.xmldrivers, and org.jsynthlib.ruby.

I believe that Hiroo suggested org.jsynthlib.jsynthlib.xml and
org.jsynthlib.jsynthlib.drivers.

I'd be fine with having xml under jsynthlib instead of core, but I
wondered if it might be confused with the actual drivers written in
xml.  I recommended a separate directory for different types of
drivers because the parser can't tell the difference between a java
file and a messed up xml file.  But I suppose I could easily solve
this by requiring xml drivers to have a common extension (.xml,
.device, or .driver come to mind as possibilities).

On Sat, 14 Aug 2004 08:31:33 -0500, Hiroo Hayashi
<hir...@co...> wrote:
> Rib,
> 
> It seems that we are thinking same thing.  Which package structure you
> need to decide now?
> 
> I'll stop changing core files for a while not to create conflict with
> you.  Are there anything I can help you for the interface change?

It'll probably be easier if I do it all myself.  I'll try to do it today.

[Jsynthlib-devel] Re: [jsynthlib-dev] Some problems

[Hiroo H. <hir...@co...>]

Denis,

denis> 2/ the master controller midi thru doesn't work, nothing is sent back to the the 
denis> synth (or any midi port). It's just to mention it because I'm using another prog 
denis> to do the MIDI thru.

I've test on my machine again and am seeing it is working.
Does MIDI Monitor show "RECV: Note On..."?

Actually I don't have MIDI keyboard in my room (although I have MIDI
piano in living room), I'm testing by using MIDI monitor (MIDI-OX).  I
believe this is fine, but I may be missing something.
-- 
Hiroo Hayashi

Re: Eclipse (was Re: [Jsynthlib-devel] Re: [jsynthlib-dev] Commit)

[<tt_...@gm...>]

Hi Ryan,

Uups, that a lot of megs to download.

I have to wait till I find a friend with a fast internet connection.

Bye
Torsten

Rib Rdb wrote:
> It's available at http://www.eclipse.org/
> 
> On Fri, 13 Aug 2004 20:08:45 +0200, tt_...@gm...
> <tt_...@gm...> wrote:
> 
>>Hi Ryan, Hi Hiroo,
>>
>>after your discussion about Eclipse, I'm interested in this tool.
>>Where is this tool available?
>>Maybe I can use it under my Linux tool.
>>
>>Bye
>>Torsten
>>
>>
>>
>>Hiroo Hayashi wrote:
>>
>>>Rib,
>>>
>>>Rib> You should be able to change the method signiture in Driver back to
>>>Rib> Patch using the refactoring, then add the new method that uses IPatch.
>>>
>>>I tried what you wrote.  It works great.  Eclipse is a really great tool.
>>>
>>>Now only subclasses of SysexWidget and Converter class use IPatch under
>>>synthdrivers.  If we decide to create IConverter class I can let
>>>subclass of Converter not to use IPatch, but I don't think it is worth
>>>to do.
>>>
>>>Probably I see why you did not let ParamModel use IPatch.  The current
>>>ParmModel depends on Patch class.  We may want to introduce IParamModel
>>>interface.
>>>
>>>I have one question about Eclipse.  I'm using the auto-build feature.
>>>It causes fails on files under midiprovider directory.  I can ignore them,
>>>but I don't want to see the fails in Problem view.  How do you handle
>>>this issue?
>>>
>>>Thanks.
>>
>>-------------------------------------------------------
>>SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
>>100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
>>Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
>>http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
>>_______________________________________________
>>Jsynthlib-devel mailing list
>>Jsy...@li...
>>https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
>>
> 
> 
> 

Re: [Jsynthlib-devel] Interfaces

[Hiroo H. <hir...@co...>]

Rib,

It seems that we are thinking same thing.  Which package structure you
need to decide now?

I'll stop changing core files for a while not to create conflict with
you.  Are there anything I can help you for the interface change?

Rib> > Do you plan to do both implementing new interfaces and package
Rib> > reorganization at the same time?  I was thinking to do interface first.
Rib> > We may make 0.20 before package reorganization because it affects on synth
Rib> > drivers a lot.
Rib> 
Rib> I was planning to do the interfaces first, then the package structure.
Rib>  I was thinking that it would just be reorganization, and that other
Rib> than imports all that would be affected are things like the devicelist
Rib> writer.  If I'm wrong, maybe we can at least decide which package the
Rib> XML driver files should go in, so that the cvs history can stay
Rib> together for these new files. Then we can move the other stuff when
Rib> we're ready.
-- 
Hiroo Hayashi

Re: [Jsynthlib-devel] Re: [jsynthlib-dev] Commit

[<tt_...@gm...>]

Hi Ryan, Hi Hiroo,

after your discussion about Eclipse, I'm interested in this tool.
Where is this tool available?
Maybe I can use it under my Linux tool.

Bye
Torsten

Hiroo Hayashi wrote:
> Rib,
> 
> Rib> You should be able to change the method signiture in Driver back to
> Rib> Patch using the refactoring, then add the new method that uses IPatch.
> 
> I tried what you wrote.  It works great.  Eclipse is a really great tool.
> 
> Now only subclasses of SysexWidget and Converter class use IPatch under
> synthdrivers.  If we decide to create IConverter class I can let
> subclass of Converter not to use IPatch, but I don't think it is worth
> to do.
> 
> Probably I see why you did not let ParamModel use IPatch.  The current
> ParmModel depends on Patch class.  We may want to introduce IParamModel
> interface.
> 
> I have one question about Eclipse.  I'm using the auto-build feature. 
> It causes fails on files under midiprovider directory.  I can ignore them,
> but I don't want to see the fails in Problem view.  How do you handle
> this issue?
> 
> Thanks.