Menu
▾
▴
jsynthlib-devel
|
From: Martin T. <m.t...@zo...> - 2011-12-26 08:54:17
|
Hi, I'm trying the refactor branch from SVN. I have not done much testing yet but it seems I am getting error messages, and failure, if I try to load a (for example) TX81Z xxx.patchlib from the current trunk in the new refactor version. Creating and then loading a new xxx.patchlib library works fine. Has backward compatibility been broken on purpose ? -- MT |
|
From: Chris W. <chr...@ch...> - 2011-12-26 11:38:03
|
Martin Tarenskeen said on 26/12/11 08:54: > > Hi, > > I'm trying the refactor branch from SVN. I have not done much testing yet > but it seems I am getting error messages, and failure, if I try to load a > (for example) TX81Z xxx.patchlib from the current trunk in the new > refactor version. Creating and then loading a new xxx.patchlib library > works fine. > > Has backward compatibility been broken on purpose ? > Damn, I'd forgotten about one of the changes I'd made - the de-serialisation of existing patchlibs wont work, as I converted several members from StringBuffers to Strings. I'll write a converter for old style patches by implementing a custom deserialisation method and checking the sereial version UID. I should get a chance to do it tomorrow (Tuesday 27th UK time). Regards, Chris |
|
From: Chris W. <chr...@ch...> - 2011-12-28 22:13:01
|
Chris Wareham said on 26/12/11 11:37: > Martin Tarenskeen said on 26/12/11 08:54: >> >> Hi, >> >> I'm trying the refactor branch from SVN. I have not done much testing yet >> but it seems I am getting error messages, and failure, if I try to load a >> (for example) TX81Z xxx.patchlib from the current trunk in the new >> refactor version. Creating and then loading a new xxx.patchlib library >> works fine. >> >> Has backward compatibility been broken on purpose ? >> > > Damn, I'd forgotten about one of the changes I'd made - the > de-serialisation of existing patchlibs wont work, as I converted several > members from StringBuffers to Strings. I'll write a converter for old > style patches by implementing a custom deserialisation method and > checking the sereial version UID. I should get a chance to do it > tomorrow (Tuesday 27th UK time). > > Regards, > > Chris > Hi Martin, I've implemented a readObject method in the Patch class, which attempts to deserialize bothe the new version of the class and the previous one that used StringBuffers for three of the data members. I have a nasty feeling that this still won't work, as the Patch class has also moved from a "core" package to an "org.jsynthlib.core" one, so the deserialization may not even get as far as my readObject method. Relying on serialised objects for long-term persistence, particularly when the data isn't held in another form as well (such an RDBMS or flat files), is asking for trouble. With JSynthLib in particular, the rather messy class hierarchy makes things even worse. If you could let me have any stack trace from attempting to read a patch library, and possibly a copy of the patchlib itself, then that would be most helpful for me to try and come up with a solution. Regards, Chris |
|
From: frankster <jsy...@te...> - 2012-02-28 17:37:30
|
Well there is a release candidate ready though we need to get in touch with the guy who controls the website so we can update it before we put the new release out. I personally have several things on my todo list when I get some time - performance editor for TX81z, a driver for the emu proteus 2000 family etc. Adding support for your device seems like a good idea to me! frankie On 28/02/12 10:42, bjb...@de... wrote: > Hi guys, > > What's the current state of affairs with JSynthLib? I see the main website > is down but I remember hearing talk of refactoring and a surge of activity > last year. Is anyone working on things now? > > I've just bought a Prophet 08 which seems to come with a decent MIDI spec > in the manual so I thought I might roll my sleeves up and have a go at > creating a driver. > > Ben > > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > Jsynthlib-devel mailing list > Jsy...@li... > https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel |
|
From: <bjb...@de...> - 2012-02-28 17:48:33
|
On Tue, Feb 28, 2012 at 05:15:42PM +0000, frankster wrote: > Well there is a release candidate ready though we need to get in touch > with the guy who controls the website so we can update it before we put > the new release out. It's been down for a while now. We might need to look at getting another site for it set up and forking, at least until the author wakes up again. My initial enthusiasm for writing the P08 code was curtailed when I couldn't find the site and hence docs. There are several other sites out there but I'm not sure if they're up to date. > I personally have several things on my todo list when I get some time - > performance editor for TX81z, a driver for the emu proteus 2000 family etc. If it gets moving again and I have success with the P08 code I'll probably look at adding to/writing TG33 and TG55/SY55 drivers too. bjb |
|
From: frankster <jsy...@te...> - 2012-02-28 18:12:48
|
There is some useful info here http://jsynthlib.wikispaces.com/ and you can browse the files that are/were on the website from the web svn viewer. http://jsynthlib.svn.sourceforge.net/viewvc/jsynthlib/trunk/JSynthLib/doc/programming.html?revision=1107&view=markup http://jsynthlib.svn.sourceforge.net/viewvc/jsynthlib/trunk/JSynthLib/doc/documentation.html?revision=954&view=markup I updated the supported synths list a few months ago and its sitting in cvs. Personally I think jsynthlib.org should redirect to jsynthlib.sf.net and host the site there instead. then it will mean that any active project admin can give people access to update the website. frankie On 28/02/12 17:48, bjb...@de... wrote: > On Tue, Feb 28, 2012 at 05:15:42PM +0000, frankster wrote: >> Well there is a release candidate ready though we need to get in touch >> with the guy who controls the website so we can update it before we put >> the new release out. > It's been down for a while now. We might need to look at getting another > site for it set up and forking, at least until the author wakes up again. > > My initial enthusiasm for writing the P08 code was curtailed when I couldn't > find the site and hence docs. There are several other sites out there but > I'm not sure if they're up to date. > >> I personally have several things on my todo list when I get some time - >> performance editor for TX81z, a driver for the emu proteus 2000 family etc. > If it gets moving again and I have success with the P08 code I'll probably > look at adding to/writing TG33 and TG55/SY55 drivers too. > > bjb > > |
|
From: Joachim <li...@sd...> - 2012-03-26 13:46:05
|
Hi, TK from the Midibox project switched to Ctrl because JSynthLib doesn't work on Mac OS X 10.7: http://midibox.org/forums/topic/16688-ctrlr-based-editor-for-mbfm/ So much for the Java benefit of platform independence. Joachim |
|
From: William Z. <wrz...@po...> - 2012-03-26 22:06:03
|
Can you blame him? Ctrlr has an active community. But yeah, I'd prefer to see him buff the Mac port rather than abandon the project completely. -Bill Zwicky On Mon, Mar 26, 2012 at 6:28 AM, Joachim <li...@sd...> wrote: > Hi, > > TK from the Midibox project switched to Ctrl because JSynthLib doesn't work > on Mac OS X 10.7: > http://midibox.org/forums/topic/16688-ctrlr-based-editor-for-mbfm/ > > So much for the Java benefit of platform independence. > > |
|
From: David G. <dg...@cs...> - 2012-03-26 22:35:19
|
On Mon, 26 Mar 2012, William Zwicky wrote: > On Mon, Mar 26, 2012 at 6:28 AM, Joachim <li...@sd...> wrote: > >> Hi, >> >> TK from the Midibox project switched to Ctrl because JSynthLib doesn't work >> on Mac OS X 10.7: >> http://midibox.org/forums/topic/16688-ctrlr-based-editor-for-mbfm/ >> >> So much for the Java benefit of platform independence. > Can you blame him? Ctrlr has an active community. But yeah, I'd prefer to > see him buff the Mac port rather than abandon the project completely. What's the problem with MacOS 10.7 and Java? -- David Griffith dg...@cs... A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? |
|
From: William Z. <wrz...@po...> - 2012-03-27 01:03:02
|
On Mon, Mar 26, 2012 at 3:16 PM, David Griffith <dg...@cs...>wrote: > >>> What's the problem with MacOS 10.7 and Java? I've heard it's just the native code that's causing trouble. The rest of it *should* work fine. -Bill Zwicky |
|
From: <chr...@ch...> - 2012-03-27 09:34:39
|
wrz...@po... wrote: > On Mon, Mar 26, 2012 at 3:16 PM, David Griffith <dg...@cs...>wrote: > > >>> What's the problem with MacOS 10.7 and Java? > > I've heard it's just the native code that's causing trouble. The rest of > it *should* work fine. > > -Bill Zwicky > Which native code is that? I can't find any either in the trunk or my refactoring branch. There is a note in the README file about the need for a MIDI provider on Mac OS X, but I wonder if this is still the case: https://developer.apple.com/library/mac/#releasenotes/CrossPlatform/JavaSnowLeopardUpdate1LeopardUpdate6RN/ResolvedIssues/ResolvedIssues.html See the Java Sound section that suggests a third party MIDI provider is no longer necessary. Judging by various posts on support forums, it looks like third party providers became problematic after these releases of the Java runtime. Regards, Chris |
|
From: Joachim <li...@sd...> - 2012-03-27 19:01:25
|
Hi, > What's the problem with MacOS 10.7 and Java? library support it seems: ---snip--- Java itself works just fine on OS X. Minecraft is a Java application, after all. The problem is that some libraries were removed from Snow Leopard that implement MIDI support. You have to now install these separately from Mandolane. They do point out it is no longer required for Lion so perhaps these added MIDI support back in? I haven't tried Java on MIDI in Lion yet actually. ---snip--- => http://midibox.org/forums/topic/16688-ctrlr-based-editor-for-mbfm/page__view__findpost__p__146872 Joachim |
|
From: Chris W. <chr...@ch...> - 2011-12-29 00:26:02
|
Martin Tarenskeen said on 28/12/11 22:42: > > Hi Chris, > > I'm attaching the patchlib file I am using for testing. > Hi Martin, I've commited a change to the AbstractLibraryFrame and Patch classes in order to handle conversion from core.Patch to org.jsynthlib.core.Patch. The patches seem to load and are being identified as Yamaha patches, but not specifically TX81Z ones. I'll test with the trunk version of JSynthLib to see if this is the same behaviour there, and if not I'll work out why tomorrow. Regards, Chris |
|
From: Martin T. <m.t...@zo...> - 2011-12-29 09:37:46
|
On Thu, 29 Dec 2011, Chris Wareham wrote: > Martin Tarenskeen said on 28/12/11 22:42: >> >> Hi Chris, >> >> I'm attaching the patchlib file I am using for testing. >> > > Hi Martin, > > I've commited a change to the AbstractLibraryFrame and Patch classes in > order to handle conversion from core.Patch to org.jsynthlib.core.Patch. > The patches seem to load and are being identified as Yamaha patches, > but not specifically TX81Z ones. I'll test with the trunk version of > JSynthLib to see if this is the same behaviour there, and if not I'll > work out why tomorrow. I am not completely happy with the TX81Z and DX100 drivers anyway. In the (I hope not too far) future I hope to be able to develop drivers that should work on the complete TX81Z "compatible" 4-op FM synths: A driver to support: DX21/27/100, DX11, TX81Z, WT11 A driver to support: YS100/200/B200/TQ5, V50, and DS55 The problem is: All these synths use the same SysEx bank format (32 patches) but bytes that are described as "usused" or "reserved" in the SysEx specs for one synth but are really used for new parameters in another synth. This should not be a big problem. Such parameters will not be recognized by some synths, but the JSynthLib drivers should be careful not to overwrite such "unused" parameter addresses with NULL values. (I have not checked yet what the current TX81Z and DX100 drivers do). For example it should be possible to load and save a TX81Z patch or bank in a DX21 ignoring the TX81Z additional parameters, but without loosing them. This is perfectly possible to handle when using the bank format (VMEM), but is a problem for separate patches: There are SIX different SysEx data formats for this: VCED (all models), ACED (TX81Z and newer), ACED2 (DX11, V50), ACED3 (V50), EFEDS (YS100/200/B200/TQ5), DLY (DS55). Therefore, in my opinion, a "universal" driver for Yamaha 4-op FM synths should store patches and banks in the compressed VMEM bankformat (128 bytes of data for one patch) even when storing individual patches. Only when sending single patches to the synth this should be converted to VCED/ACED/etc. sysex editbuffer format. Such a driver would be usable on a complete family of Yamaha synths! -- MT |
|
From: Martin T. <m.t...@zo...> - 2011-12-29 09:43:53
|
On Thu, 29 Dec 2011, Chris Wareham wrote: > I've commited a change to the AbstractLibraryFrame and Patch classes in > order to handle conversion from core.Patch to org.jsynthlib.core.Patch. > The patches seem to load and are being identified as Yamaha patches, > but not specifically TX81Z ones. I'll test with the trunk version of > JSynthLib to see if this is the same behaviour there, and if not I'll > work out why tomorrow. I tested your latest version, and on my system the patches are loaded and identified as TX81Z patches perfectly. -- MT |
|
From: Chris W. <chr...@ch...> - 2011-12-29 13:18:28
|
Martin Tarenskeen said on 29/12/11 09:43: > > > On Thu, 29 Dec 2011, Chris Wareham wrote: > >> I've commited a change to the AbstractLibraryFrame and Patch classes in >> order to handle conversion from core.Patch to org.jsynthlib.core.Patch. >> The patches seem to load and are being identified as Yamaha patches, >> but not specifically TX81Z ones. I'll test with the trunk version of >> JSynthLib to see if this is the same behaviour there, and if not I'll >> work out why tomorrow. > > I tested your latest version, and on my system the patches are loaded > and identified as TX81Z patches perfectly. > I'd forgtotten to add the TX81Z driver via the preferences panel - once I'd done that the library patcehs were identified as TX81Z patches rather than just generic Yamaha ones. It would be nice if JSL loaded the correct driver on demand, something for a wish list perhaps. OK, seeing as it doesn't look like I've broken support for existing synths, I'll now try and complete support for the Cheetah MS6. As Frankie Fisher mentioned in another mail, it's quite difficult to test without a supported device! Not sure whether this is something that could be mocked with JMock or Mockito, but it would be very useful. Chris |
|
From: Frankie F. <jsy...@te...> - 2011-12-29 10:55:21
|
On 29/12/2011 09:37, Martin Tarenskeen wrote: > I am not completely happy with the TX81Z and DX100 drivers anyway. In the > (I hope not too far) future I hope to be able to develop drivers > that should work on the complete TX81Z "compatible" 4-op FM synths: > > A driver to support: DX21/27/100, DX11, TX81Z, WT11 > > A driver to support: YS100/200/B200/TQ5, V50, and DS55 > > The problem is: All these synths use the same SysEx bank format (32 > patches) but bytes that are described as "usused" or "reserved" in the > SysEx specs for one synth but are really used for new parameters in > another synth. This should not be a big problem. Such parameters will not > be recognized by some synths, but the JSynthLib drivers should be careful > not to overwrite such "unused" parameter addresses with NULL values. (I > have not checked yet what the current TX81Z and DX100 drivers do). For > example it should be possible to load and save a TX81Z patch or bank in a > DX21 ignoring the TX81Z additional parameters, but without loosing them. > > This is perfectly possible to handle when using the bank format (VMEM), > but is a problem for separate patches: There are SIX different SysEx data > formats for this: VCED (all models), ACED (TX81Z and newer), ACED2 (DX11, > V50), ACED3 (V50), EFEDS (YS100/200/B200/TQ5), DLY (DS55). > > Therefore, in my opinion, a "universal" driver for Yamaha 4-op FM synths > should store patches and banks in the compressed VMEM bankformat (128 > bytes of data for one patch) even when storing individual patches. Only > when sending single patches to the synth this should be converted to > VCED/ACED/etc. sysex editbuffer format. > > Such a driver would be usable on a complete family of Yamaha synths! > That might work quite nicely. I have done a partial implementation of remote control stuff to get at individual patches and banks of the TX81z. However I don't have any of the other synths so its not really possible for me to do this for any of the other devices as its impossible for me to test it. Whereas if there was a universal driver, the remote control stuff that I had done for TX81z might transfer over to other synths for free (depending how the menus are set up). Plus, if someone reports a bug on e.g. the WT11, then maybe the bug is also reproducible on the TX81z which would mean it could be fixed on the TX81z as well. One of the problems for JSL that I have been pondering is how can you verify a driver still works if you don't have access to the synth - a salient point given the two refactoring efforts in progress. One approach might be to write some kind of test stubs that emulates/verifies a synth's sysex implementation. But if one driver supports several similar synths you can test 90% of the driver on the synth you happen to have. Though you still end up needing access to the synth to test the last 10% that might be specific to that one synth. frankie |
|
From: Martin T. <m.t...@zo...> - 2011-12-29 11:29:09
|
On Thu, 29 Dec 2011, Frankie Fisher wrote: > However I don't have any of the other synths so its not really > possible for me to do this for any of the other devices as its > impossible for me to test it. Whereas if there was a universal driver, > the remote control stuff that I had done for TX81z might transfer over > to other synths for free (depending how the menus are set up). Plus, if > someone reports a bug on e.g. the WT11, then maybe the bug is also > reproducible on the TX81z which would mean it could be fixed on the > TX81z as well. VMEM sysex bulk dump compatibility was the easy part when I developed the Atari program "YSEDITOR PLUS" in the 1990's. Supporting the 100-patch bankformat (actually via MIDI 128=4x32 patches) was already a bit more complicated. But supporting all these different voice editbuffer formats and different remote control messages in one program was a real nightmare. (at the end of it YSEDITOR did a pretty good job). It is true, many of the problems I had could only be solved because several people and the local music shop were willing to let me do some testing with some of these Yamaha synths at home. I have owned a YS200 and V50, I was able to do some testing with a TX81Z, DS55, WT11, and got help and feedback from people using some of the other synths, and I had all the SysEx specs. On paper - it was the time before everyone could download all manuals as PDF from the internet :-) I don't have much time and never learned to code in Java, but the know-how I aqcuired when creating YSEDITOR (I still have the GFA basic source code) could be helpful when developing a universal 4-op FM JSL driver. -- MT |
|
From: Frankie F. <jsy...@te...> - 2011-12-29 16:08:50
|
On 29/12/2011 11:29, Martin Tarenskeen wrote: > > > On Thu, 29 Dec 2011, Frankie Fisher wrote: > >> However I don't have any of the other synths so its not really >> possible for me to do this for any of the other devices as its >> impossible for me to test it. Whereas if there was a universal driver, >> the remote control stuff that I had done for TX81z might transfer over >> to other synths for free (depending how the menus are set up). Plus, if >> someone reports a bug on e.g. the WT11, then maybe the bug is also >> reproducible on the TX81z which would mean it could be fixed on the >> TX81z as well. > > VMEM sysex bulk dump compatibility was the easy part when I developed > the Atari program "YSEDITOR PLUS" in the 1990's. Supporting the > 100-patch bankformat (actually via MIDI 128=4x32 patches) was already > a bit more complicated. But supporting all these different voice > editbuffer formats and different remote control messages in one > program was a real nightmare. (at the end of it YSEDITOR did a pretty > good job). It is true, many of the problems I had could only be solved > because several people and the local music shop were willing to let me > do some testing with some of these Yamaha synths at home. I have owned > a YS200 and V50, I was able to do some testing with a TX81Z, DS55, > WT11, and got help and feedback from people using some of the other > synths, and I had all the SysEx specs. On paper - it was the time > before everyone could download all manuals as PDF from the internet :-) > > I don't have much time and never learned to code in Java, but the > know-how I aqcuired when creating YSEDITOR (I still have the GFA basic > source code) could be helpful when developing a universal 4-op FM JSL > driver. > The existing drivers might already have code that converts from VMEM to VCED etc format for sending individual patches, so maybe it wouldn't be that hard to create the specific code for each device. What about the patch editors though? Are there any different parameters in each group? Or are they all pretty much the same in that regard? Would you want to be able to edit parameters that didn't apply to the TX81z? Probably not cos it would be confusing. It wouldn't be hard to disable certain controls based on which device the driver was handling. Are the performances common across each device as well? I've started doing some work with the performances on the TX81z with the eventual plan of making an editor for them. In fact I wonder what you think is the best solution to the problem I am having. The performances refer to up to iirc 8 patches (and a few other params). These are referenced by save slot e.g. I12. If you dump the performance bank, then change the patches, the performance might not make any sense any more. So it seems like there are a few ways to do this: 1) don't do anything clever with the performance editor - just make it dump and save banks (or individual performances via remote control if necessary), and rely on the user to keep the same patches in the user bank 2) when dumping the performances also dump the user bank, and when sending a performance or performance bank to the device send the user bank as well 3) try and be clever, and when sending/receiving a performance, also send/receive any patches that the performance references as well I guess to do 2 or 3, JSL would have to store a performance dump followed by a user bank dump. But JSL doesn't really have a good mechanism for multi stage dumps (send a message, await some data, then send a different request, then wait for the second set of data). I have seen some drivers that attempt to deal with this kind of thing by putting delays into it, but they're basically putting delays into the UI thread which is a disaster. This is sometime I need to sort out before I write the P2k series driver, as that family has quite large dumps so sending/receiving needs to be implemented using flow control really for best results. Maybe the bit of code that listens for data after initiating a dump needs to be extended so that flow control can do things conditionally e.g. re-request a section if the checksum didn't add up. I guess each driver should be able to provide its own "sysex listener" that can filter out extraneous sysex (e.g. the stuff that's sometimes generated as a sideeffect of using the remote control functionality), and be able to control the flow of the dump. well that's enough rambling for one message! frankie |
|
From: John M. <jo...@as...> - 2011-12-29 16:36:37
|
FWIW, the 'performances' you describe them sound vaguely similar to Kawai K4 Multi Banks. They're basically a set of patches that define some general features such as volume, keyboard split etc then references up to 8 other patches that control the actual sounds produced. It sounds like the same sort of issue with them in that, if you move patches around in the 'single' banks, the 'multi' patch will be pointing at the wrong place. It's a big issue from an editing point of view because you probably ought to get user confirmation if you try to do anything clever and the fact the single a.d multi/performance banks are separate makes them inter-dependant in a bad way. Before I discovered JSynthLib, when I was thinking of writing a K1 editor on my own (similar structure to K4) this was something that held me back because I thought long about it without coming to a conclusion and it seemed like that decision could be important to the architecture of the application. John -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Frankie Fisher <jsy...@te...> wrote: On 29/12/2011 11:29, Martin Tarenskeen wrote: > > > On Thu, 29 Dec 2011, Frankie Fisher wrote: > >> However I don't have any of the other synths so its not really >> possible for me to do this for any of the other devices as its >> impossible for me to test it. Whereas if there was a universal driver, >> the remote control stuff that I had done for TX81z might transfer over >> to other synths for free (depending how the menus are set up). Plus, if >> someone reports a bug on e.g. the WT11, then maybe the bug is also >> reproducible on the TX81z which would mean it could be fixed on the >> TX81z as well. > > VMEM sysex bulk dump compatibility was the easy part when I developed > the Atari program "YSEDITOR PLUS" in the 1990's. Supporting the > 100-patch bankformat (actually via MIDI 128=4x32 patches) was already > a bit more complicated. But supporting all these different voice > editbuffer formats and different remote control messages in one > program was a real nightmare. (at the end of it YSEDITOR did a pretty > good job). It is true, many of the problems I had could only be solved > because several people and the local music shop were willing to let me > do some testing with some of these Yamaha synths at home. I have owned > a YS200 and V50, I was able to do some testing with a TX81Z, DS55, > WT11, and got help and feedback from people using some of the other > synths, and I had all the SysEx specs. On paper - it was the time > before everyone could download all manuals as PDF from the internet :-) > > I don't have much time and never learned to code in Java, but the > know-how I aqcuired when creating YSEDITOR (I still have the GFA basic > source code) could be helpful when developing a universal 4-op FM JSL > driver. > The existing drivers might already have code that converts from VMEM to VCED etc format for sending individual patches, so maybe it wouldn't be that hard to create the specific code for each device. What about the patch editors though? Are there any different parameters in each group? Or are they all pretty much the same in that regard? Would you want to be able to edit parameters that didn't apply to the TX81z? Probably not cos it would be confusing. It wouldn't be hard to disable certain controls based on which device the driver was handling. Are the performances common across each device as well? I've started doing some work with the performances on the TX81z with the eventual plan of making an editor for them. In fact I wonder what you think is the best solution to the problem I am having. The performances refer to up to iirc 8 patches (and a few other params). These are referenced by save slot e.g. I12. If you dump the performance bank, then change the patches, the performance might not make any sense any more. So it seems like there are a few ways to do this: 1) don't do anything clever with the performance editor - just make it dump and save banks (or individual performances via remote control if necessary), and rely on the user to keep the same patches in the user bank 2) when dumping the performances also dump the user bank, and when sending a performance or performance bank to the device send the user bank as well 3) try and be clever, and when sending/receiving a performance, also send/receive any patches that the performance references as well I guess to do 2 or 3, JSL would have to store a performance dump followed by a user bank dump. But JSL doesn't really have a good mechanism for multi stage dumps (send a message, await some data, then send a different request, then wait for the second set of data). I have seen some drivers that attempt to deal with this kind of thing by putting delays into it, but they're basically putting delays into the UI thread which is a disaster. This is sometime I need to sort out before I write the P2k series driver, as that family has quite large dumps so sending/receiving needs to be implemented using flow control really for best results. Maybe the bit of code that listens for data after initiating a dump needs to be extended so that flow control can do things conditionally e.g. re-request a section if the checksum didn't add up. I guess each driver should be able to provide its own "sysex listener" that can filter out extraneous sysex (e.g. the stuff that's sometimes generated as a sideeffect of using the remote control functionality), and be able to control the flow of the dump. well that's enough rambling for one message! frankie _____________________________________________ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _____________________________________________ Jsynthlib-devel mailing list Jsy...@li... https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel |
|
From: Martin T. <m.t...@zo...> - 2011-12-29 17:33:19
|
On Thu, 29 Dec 2011, Frankie Fisher wrote: >> I don't have much time and never learned to code in Java, but the >> know-how I aqcuired when creating YSEDITOR (I still have the GFA basic >> source code) could be helpful when developing a universal 4-op FM JSL >> driver. >> > > The existing drivers might already have code that converts from VMEM to > VCED etc format for sending individual patches, so maybe it wouldn't be > that hard to create the specific code for each device. True. But DX11 ACED2, V50 ACED3, YS200 EFEDS, and DS55 DELAY are not yet supported. > What about the patch editors though? Are there any different parameters > in each group? Or are they all pretty much the same in that regard? VCED parameters: same for all models, with a few exceptions (e.g. DX21 stereo chorus) ACED parameters: not available on DX100/27/21 ACED2 parameters: not available on DX100/27/21, TX81z ACED3 parameters: V50 only, DSP FX parameters EFEDS parameters: YS200/YS100/B200/TQ5 only, DSP FX parameters DELAY paramaters: a simple digital delay with only 2 parameters (ON/OFF, LONG/SHORT) available only on the DS55. > Would you want to be able to edit parameters that didn't apply to the > TX81z? Probably not cos it would be confusing. It wouldn't be hard to > disable certain controls based on which device the driver was handling. I think we could have several different drivers, but they could share the same patch/bank/library format and a lot of common source code. Maybe it is possible to disable those parameters that are not supported by a selected synth type, but still keep the edit parameters visible, maybe grey colored ? > Are the performances common across each device as well? I am afraid not. The DX100/DX21/27 are not multitimbral. I don't know how much the DX11 and TX81Z are similar. The V50 and is probably more complex. This model even has a bank memory for 100 performances. I have to take a look in my old YSEDITOR source code and the SysEx specs. But if I remember correctly I had to write different code for the TX81Z performances and for for example the YS200 performances. The performances look very similar (8 parts, each with things like volume, pan, patch number, note-limit H/L, etc.) but the sysex code is not compatible. But as I said, I have to look into that to be sure. -- MT |
|
From: <bjb...@de...> - 2012-02-28 11:15:45
|
Hi guys, What's the current state of affairs with JSynthLib? I see the main website is down but I remember hearing talk of refactoring and a surge of activity last year. Is anyone working on things now? I've just bought a Prophet 08 which seems to come with a decent MIDI spec in the manual so I thought I might roll my sleeves up and have a go at creating a driver. Ben |
Thanks for helping keep SourceForge clean.
X