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: Thorsten K. <Tho...@gm...> - 2005-01-23 22:48:43
|
Hi,
I'm not sure if this is related to one of the last changes in saveFrame()
or not --- it seems that it isn't possible to save a bank anymore
The problem can be reproduced in the following way:
o ensure that the Kawai K4 driver is available
o create a new library
o create a new patch, select Kawai K4/K4R Bank
o edit the new bank
o click on File->Save
Following error messages will appear:
------------------------------------------------------------------
Exception in thread "AWT-EventQueue-0" java.lang.ClassCastException: core.BankEditorFrame
at core.Actions.saveFrame(Actions.java:544)
at core.Actions$SaveAction.actionPerformed(Actions.java:977)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1849)
at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2169)
at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420)
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258)
at javax.swing.AbstractButton.doClick(AbstractButton.java:302)
at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1000)
at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1041)
at java.awt.Component.processMouseEvent(Component.java:5488)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3093)
at java.awt.Component.processEvent(Component.java:5253)
at java.awt.Container.processEvent(Container.java:1966)
at java.awt.Component.dispatchEventImpl(Component.java:3955)
at java.awt.Container.dispatchEventImpl(Container.java:2024)
at java.awt.Component.dispatchEvent(Component.java:3803)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3892)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822)
at java.awt.Container.dispatchEventImpl(Container.java:2010)
at java.awt.Window.dispatchEventImpl(Window.java:1766)
at java.awt.Component.dispatchEvent(Component.java:3803)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:234)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
------------------------------------------------------------------
(Workaround: the library which contains the bank can be saved properly)
Best Regards, Thorsten.
|
|
From: Hiroo H. <hir...@co...> - 2005-01-16 18:23:27
|
Hi Rib, I've checked in JSLFrame and JSLDeskTop which have javadoc on public methods. I just borrowed the javadoc comment from JInternalFrame and JDesktopPane. When you have time, please add more comments to help understand the code. And I found the most of JSynthLib dependent code can be removed from these classes by adding some arguments on the constructor of JSLDeskTop.=20 If you don't mind, I'll make some changes. Rib> That sounds right, but I don't have time right now to check for sure.= =20 Rib> I'll try to add some documentation as soon as I have a chance. =2E.. Rib> > BTW could you add some comments on your JSL* classes? Now they have Rib> > almost no comments. It was difficult for me to understand. And you= (we) Rib> > are thinking to move them into a independent package to be shared wi= th Rib> > other application. They needs some Java comments to be reused. Rib> >=20 Rib> > And they has some code depending for JSynthLib, AppConfig.getGuiStyl= e(), Rib> > PatchEdit.exit(), etc. Some hooks will be defined to support them f= rom Rib> > outside of the package. --=20 Hiroo Hayashi |
|
From: Hiroo H. <hir...@co...> - 2005-01-15 17:10:35
|
Hiroo> Thorsten> o Yamaha Motif (there are two drivers, one is wrong?) Hiroo> Hiroo> One of the driver is the XML version driver which is still under Hiroo> development. If we will release 0.20 before the driver completes, we Hiroo> should disable the driver detection code. Thanks for pointing out. I've added a field, DevicesConfig.useXMLDevice. By default it is set to false and XML driver is disabled. I think this is the last open issue reported recently. Am I missing something? -- Hiroo Hayashi |
|
From: Hiroo H. <hir...@co...> - 2005-01-15 16:20:19
|
I've checked in the fix. It seems working, but I've not understood all of the details of these JSL* classes yet. Please test the SDI (multiple window) mode. > all Rib> That sounds right, but I don't have time right now to check for sure. Rib> I'll try to add some documentation as soon as I have a chance. -- Hiroo Hayashi |
|
From: Thorsten K. <Tho...@gm...> - 2005-01-13 22:03:20
|
Hiroo, the last updates are working perfectly - thank you! I just have commited the MIDIboxFM driver, from my point of view we are ready for v0.20 :) Best Regards, Thorsten. |
|
From: Hiroo H. <hir...@co...> - 2005-01-12 04:46:40
|
Rib,
Yes, you are right. After I sent my mail, I read your code for a while,
and found the JSLDesktop.JSLFakeDesktop.last_selected field. I added
the following code for each class which creates JSLFrame. (This is the
easy fix I wrote, yesterday.)
public void JSLFrameDeactivated(JSLFrameEvent e) {
+ Actions.setEnabled(false, Actions.EN_ALL);
}
But this does not fix every case. I think the problem is the
'last_selected' field is not set to 'null', when it deactivated or
closed(). The latter is worse than the former. It will pointed
destroyed JSLFrame object. I guess this is the situation Eelco reported.
If I understand your code correctly, 'last_selected' must be handled as
follows;
set the current JSLFrame when it is deactivated.
set null when a JSLFrame is activated.
set null when a JSLFrame is deiconified or closed.
If deiconified or closed event can occur after deactivated method the
1st condition will be;
set the current JSLFrame when it is deactivated and (not
deiconified or closed).
Am I correct?
BTW could you add some comments on your JSL* classes? Now they have
almost no comments. It was difficult for me to understand. And you (we)
are thinking to move them into a independent package to be shared with
other application. They needs some Java comments to be reused.
And they has some code depending for JSynthLib, AppConfig.getGuiStyle(),
PatchEdit.exit(), etc. Some hooks will be defined to support them from
outside of the package.
Rib> In SDI mode, I think it remembers the last window that was focused
Rib> when the toolbar is activated and returns that as the selected frame.
Rib> If not, that's what I intended it to do.
=2E..
Rib> > Eelco> in core.Actions in the method saveFrame() a NPE is thrown
Rib> > Eelco> when the library frame is not selected. In the following snip=
pet:
Rib> >=20
Rib> > I see the problem. The current code does not care the case when no
Rib> > frame is selected. Many other command should have same problem. At =
that
Rib> > time most of commands must be disabled.
Rib> >=20
Rib> > Well, but when Tool Bar windows is used in SDI mode (multi frame mod=
e),
Rib> > no library/editor window is selected. An easy fix will make the Too=
l
Rib> > Bar window useless. I need to think more...
--=20
Hiroo Hayashi
|
|
From: Hiroo H. <hir...@co...> - 2005-01-11 04:28:53
|
Hi, JSynthLib had NextFaderAction which select the next fader bank, but did not PrevFaderAction. I've checked in the code for it. -- Hiroo Hayashi |
|
From: Hiroo H. <hir...@co...> - 2005-01-11 03:34:26
|
Eelco> Hi, I'm not sure if this is the right medium for bug reports
Eelco> (if not, what is?), but I've found a straightforward bug in saving
Eelco> a library;
The Help says;
Contributing to JSynthLib
If you like JSynthLib and want to contribute, you can do this in many
ways:
bug reports
...
The common place to address your notes should be the Tracker on
JSynthLib SourceForge site or jsynthlib-devel mailing list.
Eelco> in core.Actions in the method saveFrame() a NPE is thrown
Eelco> when the library frame is not selected. In the following snippet:
I see the problem. The current code does not care the case when no
frame is selected. Many other command should have same problem. At that
time most of commands must be disabled.
Well, but when Tool Bar windows is used in SDI mode (multi frame mode),
no library/editor window is selected. An easy fix will make the Tool
Bar window useless. I need to think more...
Anyway, thank you for your report.
--
Hiroo Hayashi
|
|
From: Eelco d. H. <ee...@ob...> - 2005-01-10 20:37:36
|
Hi, I'm not sure if this is the right medium for bug reports
(if not, what is?), but I've found a straightforward bug in saving
a library;
in core.Actions in the method saveFrame() a NPE is thrown
when the library frame is not selected. In the following snippet:
-------------------------------------
static void saveFrame()
{
try
{
AbstractLibraryFrame oFrame = (AbstractLibraryFrame) JSLDesktop
.getSelectedFrame();
-------------------------------------
the oFrame object will be null if no frame is selected; in the code
thereafter no
check is done whether oFrame is null, and a NPE will be thrown (either in
if (oFrame.getTitle().startsWith("Unsaved "))
or in
oFrame.save();
If you check the frame and click 'Save' there is no problem...
Best regards,
Eelco
|
|
From: Hiroo H. <hir...@co...> - 2005-01-10 04:17:46
|
Hi, I've checked in new Envelope Widget. Both of the issues reported by Thorsten were fixed. In addition to them I made the following changes. 1. Implement setFaderValue, setValue, setEnabled() correctly. 2. Reduce number of loop code to improve efficiency. 3. Make use of better data structure and member names. For example, now the envelope curve is moved by receiving fader control events. I made test by using KAWAI K4 and YAMAHA DX7 editor as far as possible. But I made change the code so much that I'm still afraid that I made some mistakes. Please try to test the new code with your drivers. Thanks. Thorsten> Two additional comments: Thorsten> Thorsten> o the sustain parameter of an ADSR envelope cannot be Thorsten> modified anymore, once it has reached the maximum Thorsten> value. The same is the case for the delay parameter Thorsten> of a DADRS envelope if it has the minimum value - Thorsten> this makes the envelope widget useless :-( Thorsten> Thorsten> Envelopes were working ok with 0.18, so it must be Thorsten> related to one of the last changes Thorsten> Thorsten> Thorsten> o feature request: it would be nice if the SysEx parameter Thorsten> would be sent out immediately on changes in the Thorsten> envelope. In the meantime I've replaced all envelopes Thorsten> by knobs just for better realtime control Thorsten> (-> see also http://www.ucapps.de/midibox_fm.html ) Thorsten> Thorsten> Best Regards, Thorsten. -- Hiroo Hayashi |
|
From: Hiroo H. <hir...@co...> - 2005-01-06 04:24:50
|
Rib> > Rib> I think it would be a good idea to just get rid of this positioning
Rib> > Rib> code and let the window manager do it's job.
Rib> >
Rib> > I agree with you that the window manager should do the job for multiple
Rib> > window mode.
Rib> >
Rib> > If you agree with me, I'll swap these methods.
I made a mistake. SDI mode has the following code now.
public void moveToDefaultLocation() {
setLocation(30*frame_count, 30*frame_count);
}
This creates the problem Torsten reported.
On MS Windows if I get rid of the positioning code (setLocation() call),
the new window is place on the left top corner of the screen (x = y = 0).
I cannot find the way to let the window manager place new window on a
proper place as it usually does.
# What's happen with Linux/MacOSX window managers if setLocation() is
# commented out?
I'm thinking to use the code for the current MDI mode in both MDI and
SDI mode. If there is no objection, I'll do that.
--
Hiroo Hayashi
|
|
From: Thorsten K. <Tho...@gm...> - 2005-01-05 11:22:34
|
On Wednesday 05 January 2005 02:30, Jeff Weber wrote: > I am the author of the DM5 and Line 6 Drivers. I tried > removing and adding these drivers and I was not able > to reproduce your problem on my system. On Wednesday 05 January 2005 06:39, Hiroo Hayashi wrote: > I don't have any problems for those, either. sorry for the confusion! I just found the root cause for my problems: the PACKAGES variable of the Makefile is not up-to-date. I mostly compile the code with "gmake all", but currently this doesn't cover all .java sources, therefore my built got inconsistent over the last days Am I allowed to change the Makefile in the CVS, or is this under the responsibility of somebody else? On Wednesday 05 January 2005 02:30, Jeff Weber wrote: > Thorsten, if you're subclassing the the SysexSender > class you might want to take a look at the CCSender > class in either of the Line6 packages. Thanks for the hint, a nice inspiration! :) Best Regards, Thorsten. |
|
From: Hiroo H. <hir...@co...> - 2005-01-05 05:56:40
|
Rib, Rib> If I remember correctly, I added this behavior to the JSLFrame class Rib> to copy what the previous code did. However, I think it's designed to Rib> wrap around when the windows would go offscreen. Are they Rib> disappearing off the right or bottom edge of the screen? I guess you are talking about JSLFrame.JSLIFrame.moveToDefaultLocation method (for MDI: single window mode) and JSLFrame.JSLJFrame.moveToDefaultLocation (for SDI: multiple window mode). Only latter has the code you wrote. I think this should be opposite. Rib> I think it would be a good idea to just get rid of this positioning Rib> code and let the window manager do it's job. I agree with you that the window manager should do the job for multiple window mode. If you agree with me, I'll swap these methods. -- Hiroo Hayashi |
|
From: Hiroo H. <hir...@co...> - 2005-01-05 05:41:16
|
Thorsten> > Do you know an editor which demonstrates this problem? Thorsten> Thorsten> You can test this with the Kawai K4 driver (it's also mentioned in Thorsten> the programmers tutorial, therefore a good reference) I see the problem. I guess I made this bug long time ago. I'll take this. (I checked in the fix for the bank editor bug.) Thorsten> > Once the mouse button is released, SysEx parameter should be sent out. Thorsten> > Do you want to sent out the parameters during dragging? Thorsten> Thorsten> yes, because releasing and pressing the mouse button again can be Thorsten> very knotty - it makes finetuning of an evelope very hard Thorsten> Thorsten> > It should be easy fix, but I'm afraid it might send out too many Thorsten> > messages. But it should be same as other widgets, ex. scrollbarWidgets... Thorsten> > I'd like to hear more comments about this. Thorsten> Thorsten> I don't think that the higher MIDI traffic will cause problems I've started thinking to change EnvelopveWidget class. Thorsten> Addendum: today I've tested some synth drivers, here are the results: Thorsten> Thorsten> Following drivers cannot be added in the preferences: Thorsten> o Alesis DM5 Thorsten> o Line 6 Bass Pod Thorsten> o Line 6 Pod I don't have any problems for those, either. Thorsten> o Yamaha Motif (there are two drivers, one is wrong?) One of the driver is the XML version driver which is still under development. If we will release 0.20 before the driver completes, we should disable the driver detection code. Thanks for pointing out. Thorsten> Following patch editors cannot be opened (runtime errors) Thorsten> o Emu Proteus Thorsten> o Ensoniq VSX Thorsten> o Kawai K5000 I can open editor for single patch for Emu Proteus and Kawai K5000. Ensoniq VFX driver wrongly overrode editPatch method without implementing it. I've checked in the fix. Thank you for your checking, again! -- Hiroo Hayashi |
|
From: Jeff W. <jww...@ya...> - 2005-01-05 01:31:11
|
Thorsten> Following drivers cannot be added in the Thorsten> preferences: Thorsten> o Alesis DM5 Thorsten> o Line 6 Bass Pod Thorsten> o Line 6 Pod Thorsten> o Yamaha Motif (there are two drivers, one is Thorsten> wrong?) I am the author of the DM5 and Line 6 Drivers. I tried removing and adding these drivers and I was not able to reproduce your problem on my system. Are you saying when you select any of these drivers nothing happens or are you saying they don't show up in the list. If it's the latter, I'm wondering if your synthdrivers.properties file might have somehow gotten corrupted. I would try rerunning DeviceListWriter to recreate it. Section III.e.4 in the JSynthLib Programmer's Guide (the programming.html file included in the doc folder) tells how to do this. Hiroo> Do you want to sent out the parameters during dragging? Thorsten> yes, because releasing and pressing the mouse button again can be Thorsten> very knotty - it makes finetuning of an evelope very hard Hiroo, remember when I was working on the Line6 stuff? You've already made all the necessary changes to the core code to make this possible. It's already in version 0.20. Thorsten, if you're subclassing the the SysexSender class you might want to take a look at the CCSender class in either of the Line6 packages. These are a good example of how you can have your SysexSender subclass implement the SysexWidget.ISender interface. The CCSender sends out CC messages continuously while the Widget is being adjusted. Works like a charm. You can easily modify this to send a whole sysex record or even NRPNs (The NRPNSender in the AlesisDM5 package uses this technique to send NRPNs). Hope this helps. __________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250 |
|
From: Thorsten K. <Tho...@gm...> - 2005-01-04 23:34:30
|
On Tuesday 04 January 2005 01:29, Hiroo Hayashi wrote: > Do you know an editor which demonstrates this problem? You can test this with the Kawai K4 driver (it's also mentioned in the programmers tutorial, therefore a good reference) > Once the mouse button is released, SysEx parameter should be sent out. > Do you want to sent out the parameters during dragging? yes, because releasing and pressing the mouse button again can be very knotty - it makes finetuning of an evelope very hard > It should be easy fix, but I'm afraid it might send out too many > messages. But it should be same as other widgets, ex. scrollbarWidgets... > I'd like to hear more comments about this. I don't think that the higher MIDI traffic will cause problems Addendum: today I've tested some synth drivers, here are the results: Following drivers cannot be added in the preferences: o Alesis DM5 o Line 6 Bass Pod o Line 6 Pod o Yamaha Motif (there are two drivers, one is wrong?) Following patch editors cannot be opened (runtime errors) o Emu Proteus o Ensoniq VSX o Kawai K5000 Best Regards, Thorsten. |
|
From: Mikael K. <mk...@gm...> - 2005-01-04 16:30:54
|
Hello All! :) Hiroo Hayashi wrote: > Hi Brian, > > Brian> I've placed in CVS some code I received a while back to add support > Brian> for Roland GP16 which had never made it into cvs. > Brian> I've made some changes as it was designed against 0.19-pre and doesn't > Brian> compile against current cvs. I've made most > Brian> of the changes, but there are issues w/ its use of IPatch still. Can > Brian> someone point me in the right direction here on what > Brian> the correct direction to go with this is? > Wooh, thanks! :) I thought about doing this myself, but honestly I forgot it. :) > I've checked in the fix to make compile them. The most of change I made > is replacing 'IPatch' to 'Patch'. Usually a driver extending Driver > class does not have to (should not) use IPatch. Some of other changes > should occur with 0.19-pre, I think. Anyway I only test it confirming > the single editor was invoked properly. Actual test with real device is > required. > I will be most happy to test the driver! I'm sorry if my code was very messy, but I'm not an experienced programmer... :P Thanks very much! Mikael |
|
From: Hiroo H. <hir...@co...> - 2005-01-04 00:30:42
|
Thorsten> Two additional comments: Thorsten> Thorsten> o the sustain parameter of an ADSR envelope cannot be Thorsten> modified anymore, once it has reached the maximum Thorsten> value. The same is the case for the delay parameter Thorsten> of a DADRS envelope if it has the minimum value - Thorsten> this makes the envelope widget useless :-( Thorsten> Thorsten> Envelopes were working ok with 0.18, so it must be Thorsten> related to one of the last changes Do you know an editor which demonstrates this problem? Thorsten> o feature request: it would be nice if the SysEx parameter Thorsten> would be sent out immediately on changes in the Thorsten> envelope. In the meantime I've replaced all envelopes Thorsten> by knobs just for better realtime control Thorsten> (-> see also http://www.ucapps.de/midibox_fm.html ) Once the mouse button is released, SysEx parameter should be sent out. Do you want to sent out the parameters during dragging? It should be easy fix, but I'm afraid it might send out too many messages. But it should be same as other widgets, ex. scrollbarWidgets... I'd like to hear more comments about this. -- Hiroo Hayashi |
|
From: Hiroo H. <hir...@co...> - 2005-01-04 00:12:36
|
Hi Thorsten, Thorsten> o whenever I open a patch editor, the window will be placed Thorsten> more and more into the south-east direction, regardless if Thorsten> other patch windows are opened or not. Thorsten> After I've edited more than ca. 30 patches, I have to restart Thorsten> JSynthLib, since each new editor window will be placed outside Thorsten> the desktop and is therefore not selectable I'm not sure this comes from behavior of Swing or JSLFrame class. Rib may be able to answer. Thorsten> o sorting a bank (Library->Sort) leads to an error in Thorsten> core.BankEditorFrame Thorsten> Thorsten> o it seems that the "import all" function does not work (error Thorsten> in core.BankEditorFrame) BankEditorFrame does not support Sort and 'import all' functions. The menu entries for them should be disabled. I'll fix this. -- Hiroo Hayashi |
|
From: Hiroo H. <hir...@co...> - 2005-01-03 23:58:16
|
Hi Brian, Brian> I've placed in CVS some code I received a while back to add support Brian> for Roland GP16 which had never made it into cvs. Brian> I've made some changes as it was designed against 0.19-pre and doesn't Brian> compile against current cvs. I've made most Brian> of the changes, but there are issues w/ its use of IPatch still. Can Brian> someone point me in the right direction here on what Brian> the correct direction to go with this is? I've checked in the fix to make compile them. The most of change I made is replacing 'IPatch' to 'Patch'. Usually a driver extending Driver class does not have to (should not) use IPatch. Some of other changes should occur with 0.19-pre, I think. Anyway I only test it confirming the single editor was invoked properly. Actual test with real device is required. Brian> Also, are there any issues that would prevent me from taking a cvs Brian> snapshot and putting it up on the website as 0.20? Brian> The last 'official' release is ancient and even the 0.19-pre1 on Brian> sourcefore is six months old. I made some changes on my Roland TD-6 driver during this holidays. It's trivial and almost done. I think it's good idea to release 0.20 to make the change of packaged structure proposed and discussed before. And I'd like to fix some of problems which Thorsten Klose reported. -- Hiroo Hayashi |
|
From: Thorsten K. <Tho...@gm...> - 2005-01-03 23:29:58
|
Two additional comments:
o the sustain parameter of an ADSR envelope cannot be
modified anymore, once it has reached the maximum
value. The same is the case for the delay parameter
of a DADRS envelope if it has the minimum value -
this makes the envelope widget useless :-(
Envelopes were working ok with 0.18, so it must be
related to one of the last changes
o feature request: it would be nice if the SysEx parameter
would be sent out immediately on changes in the
envelope. In the meantime I've replaced all envelopes
by knobs just for better realtime control
(-> see also http://www.ucapps.de/midibox_fm.html )
Best Regards, Thorsten.
|
|
From: Thorsten K. <Tho...@gm...> - 2005-01-03 23:07:41
|
Hi Brian,
On Monday 03 January 2005 22:54, Brian Klock wrote:
> Also, are there any issues that would prevent me from taking a cvs
> snapshot and putting it up on the website as 0.20?
> The last 'official' release is ancient and even the 0.19-pre1 on
> sourcefore is six months old.
could you please wait for 1-2 weeks until I've finalized the
MIDIbox FM driver? The synth itself is currently under development,
therefore I cannot finish the driver before all sound features are
ready for use.
My advantage would be that I don't have to publish a seperate
JSynthLib release for MIDIbox users anymore (who mostly don't
have experiences with CVS, compiling java code, etc...)
Some general comments to things which I've noticed with the current
snapshot (all are independent from the synthdrivers):
o whenever I open a patch editor, the window will be placed
more and more into the south-east direction, regardless if
other patch windows are opened or not.
After I've edited more than ca. 30 patches, I have to restart
JSynthLib, since each new editor window will be placed outside
the desktop and is therefore not selectable
o sorting a bank (Library->Sort) leads to an error in
core.BankEditorFrame
o it seems that the "import all" function does not work (error
in core.BankEditorFrame)
Best Regards, Thorsten.
|
|
From: Brian K. <bk...@ne...> - 2005-01-03 21:47:54
|
Hello,
I've placed in CVS some code I received a while back to add support
for Roland GP16 which had never made it into cvs.
I've made some changes as it was designed against 0.19-pre and doesn't
compile against current cvs. I've made most
of the changes, but there are issues w/ its use of IPatch still. Can
someone point me in the right direction here on what
the correct direction to go with this is?
Also, are there any issues that would prevent me from taking a cvs
snapshot and putting it up on the website as 0.20?
The last 'official' release is ancient and even the 0.19-pre1 on
sourcefore is six months old.
Brian
|
|
From: Thorsten K. <Tho...@gm...> - 2004-12-22 13:18:31
|
On Wednesday 22 December 2004 07:44, Joachim Backhaus wrote: > > I've written a small testcase (the error is still reproducible) > > and submitted a bug report > > Can you post the bug number here? I will do that once the bug is in the database. Currently it's "under review" Best Regards, Thorsten. |
|
From: Joachim B. <jba...@pi...> - 2004-12-22 06:44:38
|
> I've written a small testcase (the error is still reproducible) > and submitted a bug report Can you post the bug number here? Would be helpful because the JSynthLib Developer Team can then watch the progress of the Bugfix. Regards, Joachim Backhaus > -----Urspr=FCngliche Nachricht----- > Von: jsy...@li... > [mailto:jsy...@li...]Im Auftrag von > Thorsten Klose > Gesendet: Dienstag, 21. Dezember 2004 23:33 > An: jsy...@li... > Betreff: Re: AW: [Jsynthlib-devel] General problem with sending SysEx > messages? >=20 >=20 >=20 > On Tuesday 21 December 2004 12:02, Joachim Backhaus wrote: > > If you cannot found it there, please report the bug here: > > http://bugs.sun.com/services/bugreport/index.jsp >=20 > thanks, I didn't know this database. >=20 > I've written a small testcase (the error is still reproducible) > and submitted a bug report >=20 > Best Regards, Thorsten. >=20 >=20 > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from=20 > real users. > Discover which products truly live up to the hype. Start reading now.=20 > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Jsynthlib-devel mailing list > Jsy...@li... > https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel >=20 |
89 messages has been excluded from this view by a project administrator.
