Menu
▾
▴
jsynthlib-devel — Mailing list for developers and users interested in improving the JSynthLib.
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(90) |
Sep
(38) |
Oct
(22) |
Nov
(3) |
Dec
(13) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(40) |
Feb
(119) |
Mar
(236) |
Apr
(41) |
May
(45) |
Jun
(10) |
Jul
(9) |
Aug
(12) |
Sep
(5) |
Oct
(17) |
Nov
(2) |
Dec
(3) |
| 2006 |
Jan
(23) |
Feb
(36) |
Mar
(49) |
Apr
|
May
|
Jun
(1) |
Jul
(11) |
Aug
(11) |
Sep
(15) |
Oct
(30) |
Nov
(36) |
Dec
(13) |
| 2007 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
(3) |
Jun
(7) |
Jul
(4) |
Aug
(1) |
Sep
(19) |
Oct
(1) |
Nov
(2) |
Dec
(5) |
| 2008 |
Jan
|
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(5) |
Dec
|
| 2009 |
Jan
(26) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(26) |
Sep
(6) |
Oct
(5) |
Nov
(6) |
Dec
(6) |
| 2010 |
Jan
(3) |
Feb
|
Mar
(5) |
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
(6) |
Aug
(8) |
Sep
(220) |
Oct
(9) |
Nov
(27) |
Dec
(33) |
| 2012 |
Jan
|
Feb
(4) |
Mar
(9) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
| 2013 |
Jan
(6) |
Feb
(20) |
Mar
(6) |
Apr
(3) |
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(17) |
Nov
(2) |
Dec
|
| 2014 |
Jan
(9) |
Feb
(1) |
Mar
(11) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
(2) |
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Hiroo H. <hir...@co...> - 2005-02-18 02:29:03
|
Jeff, We need more info. Jeff> There seems to be an intermittant bug somewhere in the Jeff> core code where the start byte (the F0 byte) of the Jeff> sysex record sometimes gets overwritten. Sometimes the What do you mean by 'sometimes'? Can you (we) reproduce the problem? Jeff> first bit gets changed to zero and sometimes it's the Jeff> first couple of bits. It looks like it might be Jeff> happening in the PatchBasket class. When sending a How do you conclude that "it might be happening in the PatchBasket class"? # Patchbasket is an interface not a class. Jeff> patch down to a device, this results in an invalid Jeff> sysex message. How did you know this? -- Hiroo Hayashi |
|
From: Hiroo H. <hir...@co...> - 2005-02-18 02:28:57
|
Brian, Brian> The only issue is that when Brian> you attempt to load Brian> an editor that needs 1.5 on a 1.4 system it should give a meaningful Brian> error message and fail Brian> gracefully. The issue I'm thinking is that every time JDK 1.4 users compile JSynthlib, 1.5 code cause compile error. They have to check the each compile error if it is due to 1.5 code or not. I'm OK because I'm using JDK 1.5. But I don't like it, if I were JDK 1.4 user. -- Hiroo Hayashi |
|
From: Hiroo H. <hir...@co...> - 2005-02-18 02:28:37
|
Joe> I'm eager to help out on something... so I'm wondering what next feature Joe> everybody is trying to get into JSL. I could go scour the archvies, but Joe> it seems easier just to ask to see what the "hot" items are these days. There are two proposal. 1. XML driver 2. package structure change (move to org.jsynthlib) 2.1 making consensus We had discussion and I made summary a few times. But I could not continue the job for my laziness. 2.2 making change It is too much work for a person to make the all of changes. How can we share the work? I think the refactoring feature in Eclipse may reduce the work a lot, but I'm not sure. -- Hiroo Hayashi |
|
From: Jeff W. <jww...@ya...> - 2005-02-17 20:13:30
|
There seems to be an intermittant bug somewhere in the core code where the start byte (the F0 byte) of the sysex record sometimes gets overwritten. Sometimes the first bit gets changed to zero and sometimes it's the first couple of bits. It looks like it might be happening in the PatchBasket class. When sending a patch down to a device, this results in an invalid sysex message. I've been getting around this in my drivers by overriding the sendPatch method, setting the first byte back to F0, and then calling the overridden sendPatch method. I ran into this some time ago and forgot to report it. __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com |
|
From: Chris P. <chr...@ma...> - 2005-02-17 18:04:21
|
Hi, As on observer on this list ... If you make free software dependent on Java 1.5, it is much further away from working with the free Java runtimes that use GNU Classpath. As it stands, there is not *much* preventing the use of JSynthLib within a completely free environment, but if you make 1.5 required it becomes quite a pain. I know you're planning on keeping the core 1.4-compliant for now, but if and when you do make the switch, this is something to keep in mind. Also, I bet it's not difficult to go and make the driver 1.4-compliant. The drivers are typically small and the new features in 1.5 are for the most part just conveniences. Cheers, Chris Brian wrote: > I think It makes sense to make JDK1.4.1 the minimum requirement for > JSynthlib. > We need to keep 1.5 specific code out of the JSynthLib core, but It > shouldn't be a problem > to include synth editors dependant on 1.5. The only issue is that when > you attempt to load > an editor that needs 1.5 on a 1.4 system it should give a meaningful > error message and fail > gracefully. We can put right on the 'supported synths' part of the > website that this editor > requires 1.5. This way those who really need that editor and have 1.5 > can get easy access to it, > but we make it cleear that its not supported on all systems. > > Brian > > Hiroo Hayashi wrote: > >> As you comment on the RFE, JRE 1.5 cannot be requirement because there >> is no 1.5 JRE for Mac OS X. And even if 1.5 JRE for Mac OS X is >> released, it's too early to make it requirement. >> >> But I think it should be more easy not to use Java 1.5 feature than to >> use different library. >> >> BTW Xavier wrote he was using XML for editor layout. Rib started same >> work and some code was checked-in, but it is stalling since he has been >> busy. Can these effort be merged? >> >> Joachim> Xavier (don't know the surname) has developed >> Joachim> synthdriver support for the Roland JV1080 >> Joachim> (see feature request 1088898) but it >> Joachim> works only with JRE 1.5. >> Joachim> Joachim> Can add the code to JSynthLib anyhow >> Joachim> with a note that the driver needs JRE 1.5? >> >> > > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Jsynthlib-devel mailing list > Jsy...@li... > https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel > |
|
From: Brian <br...@ov...> - 2005-02-17 15:15:10
|
I think It makes sense to make JDK1.4.1 the minimum requirement for JSynthlib. We need to keep 1.5 specific code out of the JSynthLib core, but It shouldn't be a problem to include synth editors dependant on 1.5. The only issue is that when you attempt to load an editor that needs 1.5 on a 1.4 system it should give a meaningful error message and fail gracefully. We can put right on the 'supported synths' part of the website that this editor requires 1.5. This way those who really need that editor and have 1.5 can get easy access to it, but we make it cleear that its not supported on all systems. Brian Hiroo Hayashi wrote: >As you comment on the RFE, JRE 1.5 cannot be requirement because there >is no 1.5 JRE for Mac OS X. And even if 1.5 JRE for Mac OS X is >released, it's too early to make it requirement. > >But I think it should be more easy not to use Java 1.5 feature than to >use different library. > >BTW Xavier wrote he was using XML for editor layout. Rib started same >work and some code was checked-in, but it is stalling since he has been >busy. Can these effort be merged? > >Joachim> Xavier (don't know the surname) has developed >Joachim> synthdriver support for the Roland JV1080 >Joachim> (see feature request 1088898) but it >Joachim> works only with JRE 1.5. >Joachim> >Joachim> Can add the code to JSynthLib anyhow >Joachim> with a note that the driver needs JRE 1.5? > > |
|
From: Joe E. <jo...@em...> - 2005-02-17 06:07:10
|
My apologies for dropping off of the map for a year-and-a-half. When I drifted off back then, there was some eager talk about implementing XML-based patch driver specs. Since I've been watching CVS all this time, I've noticed that there's been some work in this area. I'm eager to help out on something... so I'm wondering what next feature everybody is trying to get into JSL. I could go scour the archvies, but it seems easier just to ask to see what the "hot" items are these days. - Joe |
|
From: Hiroo H. <hir...@co...> - 2005-02-17 04:38:02
|
As you comment on the RFE, JRE 1.5 cannot be requirement because there is no 1.5 JRE for Mac OS X. And even if 1.5 JRE for Mac OS X is released, it's too early to make it requirement. But I think it should be more easy not to use Java 1.5 feature than to use different library. BTW Xavier wrote he was using XML for editor layout. Rib started same work and some code was checked-in, but it is stalling since he has been busy. Can these effort be merged? Joachim> Xavier (don't know the surname) has developed Joachim> synthdriver support for the Roland JV1080 Joachim> (see feature request 1088898) but it Joachim> works only with JRE 1.5. Joachim> Joachim> Can add the code to JSynthLib anyhow Joachim> with a note that the driver needs JRE 1.5? -- Hiroo Hayashi |
|
From: Hiroo H. <hir...@co...> - 2005-02-17 04:27:58
|
Eelco> > I've checked in the fix, since this was my fault. The compiler built-in
Eelco> > Eclipse does not detect this.
Eelco>
Eelco> In Eclipse you enable warnings on deprecated methods:
Eelco> Window->Preferences->Java->Compiler
Eelco> Tab 'Advanced'; change 'Usage of deprecated API' to 'Warning'.
Thanks. But I'm also using this default setting. Problem is...
/**
* If the internal frame is not visible, brings the internal frame to the
* front, makes it visible, and attempts to select it.
* @deprecated use setVisible().
*/
//public void show() { proxy.show(); }
/** Causes subcomponents of this frame to be laid out at their preferred size. */
public void pack() { proxy.pack(); }
Eclipse does not treat "pack()" deprecated, but Joe's compiler (probably
Sun standard compiler) does.
I don't know which is correct behavior.
--
Hiroo Hayashi
|
|
From: Joachim B. <jba...@pi...> - 2005-02-16 08:50:39
|
Hi, Xavier (don't know the surname) has developed synthdriver support for the Roland JV1080 (see feature request 1088898) but it works only with JRE 1.5. Can add the code to JSynthLib anyhow with a note that the driver needs JRE 1.5? Regards, Joachim Backhaus |
|
From: Eelco d. H. <ee...@ob...> - 2005-02-16 07:56:29
|
> I've checked in the fix, since this was my fault. The compiler built-in > Eclipse does not detect this. In Eclipse you enable warnings on deprecated methods: Window->Preferences->Java->Compiler Tab 'Advanced'; change 'Usage of deprecated API' to 'Warning'. Cheers, Eelco |
|
From: Hiroo H. <hir...@co...> - 2005-02-16 04:30:31
|
OK. I'll stop checking in except bug fix. -- Hiroo Hayashi |
|
From: Hiroo H. <hir...@co...> - 2005-02-16 04:26:41
|
Rib> Wouldn't it be better to remove show than comment it out, since we can Rib> get it from CVS if we ever need it again? I've been trying to remain some hint when I made a change which may require modification on synth driver which is not in CVS. That's the reason why we have many deprecated methods. But I think we can remove most of them once we release 0.20. -- Hiroo Hayashi |
|
From: Rib R. <ri...@gm...> - 2005-02-15 17:49:09
|
I don't remember if I said I wanted to wait until I had the XML editor support written. There's no way I'm going to have time to even start it until after March, so don't wait for that. On Tue, 15 Feb 2005 11:13:54 -0500, Brian Klock <bk...@ne...> wrote: > Hello, > > Back in January I asked about doing a 0.20 release based on CVS head > and received many messages on and off list asking me to hold off for > various features and fixes. > Some of those have been added to head, but some of the people who asked > me to hold off have fallen out of contact. Unless there are any serious > "show stopper" bugs, > I plan to branch off a 0.20 release for the website (which would then > finally be updated) this month. My plan is to set a "hard" deadline of > February 23rd. Any changes > to CVS made after this date will not make it into 0.20. On February 24th > I will compile a release candidate and make it available for testing. If > there are no serious issues > outstanding, I intend to release 0.20 on March 1st. > > Thanks > > Brian > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Jsynthlib-devel mailing list > Jsy...@li... > https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel > |
|
From: Brian K. <bk...@ne...> - 2005-02-15 16:07:01
|
Hello,
Back in January I asked about doing a 0.20 release based on CVS head
and received many messages on and off list asking me to hold off for
various features and fixes.
Some of those have been added to head, but some of the people who asked
me to hold off have fallen out of contact. Unless there are any serious
"show stopper" bugs,
I plan to branch off a 0.20 release for the website (which would then
finally be updated) this month. My plan is to set a "hard" deadline of
February 23rd. Any changes
to CVS made after this date will not make it into 0.20. On February 24th
I will compile a release candidate and make it available for testing. If
there are no serious issues
outstanding, I intend to release 0.20 on March 1st.
Thanks
Brian
|
|
From: Hiroo H. <hir...@co...> - 2005-02-15 12:15:59
|
Hi Joe, Long time no see you. I missed you since you suddenly disappeared from this mailing list. Anyway welcome back! Joe> It appears that, a couple of weeks ago, the "show()" method was both Joe> deprecated *and* commented out in core.JSLFrame. I've checked in the fix, since this was my fault. The compiler built-in Eclipse does not detect this. -- Hiroo Hayashi |
|
From: Joe E. <jo...@em...> - 2005-02-15 10:36:24
|
It appears that, a couple of weeks ago, the "show()" method was both deprecated *and* commented out in core.JSLFrame. My compiler applies deprecation to the first UNcommented method it comes across. Since show() is commented out, the compiler thinks that the one *after* it, currently pack(), is deprecated. As a result, I'm getting dozens of deprecation warnings when I try to do a rebuild from the current cvs tree. If nobody objects in about 24 hours, I'm going to remove the deprecation. After all, there's no point. show() isn't just deprecated.... it's *gone*. - Joe |
|
From: Hiroo H. <hir...@co...> - 2005-02-14 05:00:58
|
The fix is in head. I made the logic more simple than before. I may be
wrong as you guys know. Try and let me know you see something wrong.
denis> Actually I completely forgot the contextual menu and other menu since I use the
denis> icon all the time, stupid isn't it ?...
It's interesting you always use icon, and I never use it, isn't it?
Well, your comment made my todo list longer.
Add balloon help on tool bar.
I don't use icon because I cannot imagine the job of some of icons.
--
Hiroo Hayashi
|
|
From: Jeff W. <jww...@ya...> - 2005-02-14 00:56:25
|
Just a note Mac OSX signal errors. I tried Plumstone
but was unable to get it working. However I did some
experimentation with CAProvider yesterday and
discovered a couple of modifications to the
core.MidiUtil.java class that will at least cut down
on the frequency of signal errors. First of all, I was
having a lot of problems with the Behringer FCB1010.
This device only has one type of patch with a length
of 2352. Since it's a fairly large patch and since I
wasn't getting as many signal errors as with the other
devices, I suspected that the problem might be some
kind of a timing issue.
First, I changed the value of BUFSIZE from 0 to 256
which causes the MIDI data to be sent in multiple
blocks of 256 bytes. Then I added a 100 millisecond
delay at the end of the send(Receiver rcv, MidiMessage
msg) method. The whole thing looks like this:
/**
* MIDI Output buffer size. If set to '0', Whole
Sysex data is
* sent in one packet. Set '0' unless you have
problem.
*/
private static final int BUFSIZE = 256;
/**
* Send a <code>MidiMessage</code>. If BUFSIZE is
non-zero, data
* size will be limited to the size.
*/
public static void send(Receiver rcv, MidiMessage
msg)
throws MidiUnavailableException,
InvalidMidiDataException {
int size = msg.getLength();
if (BUFSIZE == 0 || size <= BUFSIZE) {
rcv.send(msg, -1);
log("XMIT: ", msg);
} else {
// divide large System Exclusive
Message into multiple
// small messages.
byte[] sysex = msg.getMessage();
byte[] tmpArray = new byte[BUFSIZE +
1];
for (int i = 0; size > 0; i +=
BUFSIZE, size -= BUFSIZE) {
int s = Math.min(size, BUFSIZE);
if (i == 0) {
System.arraycopy(sysex, i,
tmpArray, 0, s);
((SysexMessage)
msg).setMessage(tmpArray, s);
} else {
tmpArray[0] = (byte)
SysexMessage.SPECIAL_SYSTEM_EXCLUSIVE;
System.arraycopy(sysex, i,
tmpArray, 1, s);
((SysexMessage)
msg).setMessage(tmpArray, ++s);
}
rcv.send(msg, -1);
log("XMIT: ", msg);
try {
Thread.sleep (100);
} catch (Exception e) {}
}
}
}
I realize this is only a temporary workaround. While
it doesn't totally eliminate signal errors I'm getting
way fewer of them than I was getting.
I have only made these changes to my local copy and I
don't plan on committing the changes, since they would
only apply to Mac users and would only be a temporary
workaround at best. But for any of you who are Mac
users and don't want to use Plumstone, this might be
another alternative.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
|
|
From: denis q. <dqu...@fr...> - 2005-02-13 22:39:54
|
Hiroo Hayashi wrote: > Denis, > > I'd been thinking your problem was Mac specific and was difficult for me > to debug. But your log showed me it could reproduce on any platform. > > You invoke editor by using menu bar of Toolbar window. This causes null > pointer exception. Menu bar of the library window and pop up menu > (right click menu), which I already use, should not have problem. Yes, it fails with the toolbar "edit" button, but it works with the menu and the contextual menu. Actually I completely forgot the contextual menu and other menu since I use the icon all the time, stupid isn't it ?... -- Denis |
|
From: Hiroo H. <hir...@co...> - 2005-02-13 21:23:20
|
Denis, I'd been thinking your problem was Mac specific and was difficult for me to debug. But your log showed me it could reproduce on any platform. You invoke editor by using menu bar of Toolbar window. This causes null pointer exception. Menu bar of the library window and pop up menu (right click menu), which I already use, should not have problem. It should be easy to be fixed. Thank you for your help! -- Hiroo Hayashi |
|
From: Hiroo H. <hir...@co...> - 2005-02-13 21:04:55
|
Rib> > The following implementation may be better. Rib> > Rib> > No toolbar window on MacOS Rib> > toolbar is attached on every frame. Rib> > toolbar can be removed by user preference. Rib> > default is enabled on MacOS, and is disabled on other OSs. Rib> > Rib> > How do you think? Rib> Rib> That sounds really good. OK. I'll do that. Rib> > I cannot accept "JSLJSLFrame". "MyFrame" is a candidate. I don't like Rib> > it, but have no better name. Rib> > Rib> > Another way is to rename "JSLDesktop"/"JSLFrame" class. For example Rib> > "MMDesktop" and "MMFrame". "MM" stands for "Multi Mode". Rib> > Rib> > Do you have any suggestion? Rib> Rib> How about something like MenuFrame or JSLMenuBarFrame? Sold! -- Hiroo Hayashi |
|
From: denis q. <dqu...@fr...> - 2005-02-13 19:14:04
|
Hiroo Hayashi wrote: > Denis, > > I'm getting closer. It seems that my first bug fix for JSLDeaktop Rev. > 1.15 made the bug. > > Give me your console output with the debug mode enabled (-D -1). It > must help me a lot. this is the log (the getSelectedFrame = null was added by me): JSynthLib: 0.20-alpha, Java: 1.4.2_05, OS: Mac OS X, 10.3.7 Found new FastLane device 0x4003 Using FastLane device 0x4003 Found new FastLane device 0x5403 Using FastLane device 0x5403 JAR: Initialize [inSelf, name] : 3290048 java JAR: kAudioHardwarePropertyProcessIsMaster err theSize 0 4 JAR: kAudioHardwarePropertyProcessIsMaster err outData 0 0 cannot connect to jack server cannot connect to default JACK server JAR: jack server not running? open inport: Port A (MidiIN:0), port: 0 open inport: Port B (MidiIN:1), port: 1 open outport: Port B (MidiOUT:1), port: 6 "Please enable ScreenMenuBar." activated (0) "Please enable ScreenMenuBar." opened (0) "Please enable ScreenMenuBar." deactivated (0) "JSynthLib Tool Bar" activated (0) "JSynthLib Tool Bar" selected : core.JSLFrame$JSLJFrame[frame0,0,22,500x80,layout=java.awt.BorderLayout,title=JSynthLib Tool Bar,resizable,normal,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,0,22,500x58,layout=javax.swing.JRootPane$RootLayout,alignmentX=null,alignmentY=null,border=,flags=385,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true] "JSynthLib Tool Bar" opened (0) "JSynthLib Tool Bar" deactivated (0) "Unsaved Library #1" activated (0) "Unsaved Library #1" selected : core.JSLFrame$JSLJFrame[frame1,0,102,600x300,invalid,layout=java.awt.BorderLayout,title=Unsaved Library #1,resizable,normal,defaultCloseOperation=DISPOSE_ON_CLOSE,rootPane=javax.swing.JRootPane[,0,22,600x278,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=null,alignmentY=null,border=,flags=385,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true] "Unsaved Library #1" opened (0) "Unsaved Library #1" deactivated (0) Bingo Oberheim Matrix 1000 Single LibraryFrame.addPatch: Patch=[Oberheim Matrix 1000 Single] f0 10 06 0d 00 0e 04 05 06 07 07 00 05 01 06 04 .. 00 1a f7 "Unsaved Library #1" activated (0) JSynthLib finalizing... "Unsaved Library #1" selected : core.JSLFrame$JSLJFrame[frame1,0,102,600x300,invalid,layout=java.awt.BorderLayout,title=Unsaved Library #1,resizable,normal,defaultCloseOperation=DISPOSE_ON_CLOSE,rootPane=javax.swing.JRootPane[,0,22,600x278,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=null,alignmentY=null,border=,flags=385,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true] "Unsaved Library #1" deactivated (0) "JSynthLib Tool Bar" activated (0) "Unsaved Library #1" FakeActivated "Unsaved Library #1" activated (0) "Unsaved Library #1" selected : core.JSLFrame$JSLJFrame[frame1,0,102,600x300,invalid,layout=java.awt.BorderLayout,title=Unsaved Library #1,resizable,normal,defaultCloseOperation=DISPOSE_ON_CLOSE,rootPane=javax.swing.JRootPane[,0,22,600x278,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=null,alignmentY=null,border=,flags=385,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true] "JSynthLib Tool Bar" selected : core.JSLFrame$JSLJFrame[frame0,0,22,500x80,invalid,layout=java.awt.BorderLayout,title=JSynthLib Tool Bar,resizable,normal,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,0,22,500x58,layout=javax.swing.JRootPane$RootLayout,alignmentX=null,alignmentY=null,border=,flags=385,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true] getSelectedFrame = null "JSynthLib Tool Bar" deactivated (0) |
|
From: Hiroo H. <hir...@co...> - 2005-02-13 18:47:59
|
Hi Rib,
Rib> > For other OSs, the toolbar looks like a kind of the center window. But
Rib> > for MacOSX it looks line just a one of frames.
Rib> >
Rib> > Is this the common way for toolbar in SDI mode on MacOSX?
Rib>
Rib> Actually Mac programs are not supposed to have this type of
Rib> "application global" toolbar. Instead all functions should be
Rib> accesible from the menus, and possibly also keyboard shortcuts. If
Rib> toolbars do exist, they are supposed to be attached to the window that
Rib> they act on. The user is supposed to be able to chose which buttons
Rib> are on the toolbar, or hide the toolbar entirely.
The following implementation may be better.
No toolbar window on MacOS
toolbar is attached on every frame.
toolbar can be removed by user preference.
default is enabled on MacOS, and is disabled on other OSs.
How do you think?
Rib> > To keep the current behavior JSynthLib can add menubar on JSLFrame
Rib> > (which does not have menu bar by default) by extending JSLFrame.
Rib> >
Rib> > I think this is a flexible and clean way. The biggest problem now I see
Rib> > is the name of the extended class.
Rib> >
Rib> > org.jsynthlib.jsynthlib.JSLJSLFrame class !!!?
Rib>
Rib> Again, this design was based on the Mac interface guidelines -- The
Rib> menu items stay constant for the whole application, but may be enabled
Rib> or disabled based on what window is active instead of having menu
Rib> items added or removed over time. But you are right, maybe this
Rib> shouldn't be required by the JSLDesktop classes.
OK. Extending JSLDesktop/JSLFrame class seems a right way .
I cannot accept "JSLJSLFrame". "MyFrame" is a candidate. I don't like
it, but have no better name.
Another way is to rename "JSLDesktop"/"JSLFrame" class. For example
"MMDesktop" and "MMFrame". "MM" stands for "Multi Mode".
Do you have any suggestion?
--
Hiroo Hayashi
|
|
From: Hiroo H. <hir...@co...> - 2005-02-13 18:18:43
|
Denis, I'm getting closer. It seems that my first bug fix for JSLDeaktop Rev. 1.15 made the bug. Give me your console output with the debug mode enabled (-D -1). It must help me a lot. Thanks. On Sun, 13 Feb 2005 12:06:09 +0100 denis queffeulou <dqu...@fr...> wrote: denis> > Denis: denis> > NullPointerException occurs every time (?) edit for Matrix or FS1R , denis> > single or bank is invoked (?). denis> > denis> > Is this correct? denis> yes denis> denis> > Which Matrix driver you mentioned, Matrix 1000 or Matrix 6[R]? denis> denis> 1000 denis> denis> > Are there any editor which does not cause the error? In other words, are denis> > these all of ther driver you tested? denis> > denis> > How about you, other MacOS X users? denis> > denis> > denis> The error was: denis> > denis> null denis> > denis> The exception text is: denis> > denis> java.lang.NullPointerException denis> > denis> at core.Actions$EditAction$Worker.run(Unknown Source) denis> > denis> > Can you get normal(?) stack trace which has line number information? denis> > But I suspect getSelectedFrame() on the line 797 in Actions.java may denis> > be causing the exception. It's just because I made a change of it denis> > recently. denis> denis> you 're right, the method getSelectedFrame() returns null denis> denis> -- denis> Denis -- Hiroo Hayashi |
89 messages has been excluded from this view by a project administrator.
