Menu
▾
▴
jsynthlib-devel
|
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...> - 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: 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: 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: 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: 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: 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-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: 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-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-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-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: 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: 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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X