From: Joachim B. <jba...@pi...> - 2005-02-25 13:19:24
|
> Of course, we could take this further and have arrays for each type... = > listing the types in various languages (in anticipation of a = multi-language version down the road someday). Maybe we should read the values from property files with english names as default and naming the files using locale IDs. E.g. gui.properties <- default values gui_de.properties <- values for german language gui_fr.properties <- values for french language gui_en_US.properties <- values for american-english gui_en_GB.properties <- values for british-english And e.g. the constants just include the key: public static final String DEV_TYPE_SYNTH =3D = classification.device-type.synthesizer"; public static final String DEV_TYPE_DRUM =3D = "classification.device-type.drum-machine"); A content example could be: English: classification.device-type.drum-machine =3D Drum Machine German: classification.device-type.drum-machine =3D Schlagzeugmodul Maybe it would be nice to have a "Classification" class with methods like: public String getDeviceType(String key) <- Use the system's default = locale public String getDeviceType(String key, Locale locale) <- Use a specific = locale and the constants. Multiple classifications could relatively easy be done by using a String array. But I don't know if that would be the best way. Regards, Joachim Backhaus -----Urspr=FCngliche Nachricht----- Von: jsy...@li... = [mailto:jsy...@li...]Im Auftrag von Joe = Emenaker Gesendet: Donnerstag, 24. Februar 2005 22:48 An: JSynthLib Development Betreff: Re: AW: [Jsynthlib-devel] Switch to JTree for the device list? Joachim Backhaus wrote:=20 However, it would be even nicer if we could start classifying the=20 devices as, say, synthesizer, drum machine, foot controller,=20 etc. =20 I think that's a very good idea. Hmm, should the classification be done via the Device class using a new field "classification" or "type" as String? Should constants be used for the classifcations? Else it may be that one developer classifies the driver as being a "synthesizer" and another as "synthesiser" (Great = britain). =20 If I could carve it in stone and send it over email, I would:=20 Individual synthdrivers should NOT be able to make up their = own classification string. Individual synthdrivers should NOT be able to make up their = own classification string. Individual synthdrivers should NOT be able to make up their = own classification string. The only way to do this (that I can see) which won't lead to chaos down = the road is to have defined constants in the core app, like: public static final String DEV_TYPE_SYNTH =3D "Synthesizer"; public static final String DEV_TYPE_DRUM =3D "Drum Machine"; Of course, we could take this further and have arrays for each type... = listing the types in various languages (in anticipation of a = multi-language version down the road someday). Of course, there are some judgement calls that would have to be made. = Many keyboard synths are controllers *and* synths (ie a keyboard = controller and a rackmount synth) in the same box. They're probably best = categorized together with the rackmount synths. Ok, I state an example here how I understood it: Default tree uses manufactures, e.g.: Behringer -> FCB-1010 Quasimidi -> Quasar Roland -> JV-80 -> JV-1080 And a possibility is offered (via button or so) to order it by a classification, e.g.: MIDI Controller -> Behringer FCB-1010 Synthesizer -> Quasimidi Quasar -> Roland JV-80 -> Roland JV-1080 =20 Exactly! There'd also be the possibility of multiple levels like: MIDI Controller -> Art ---> X-11 ---> X-15 Ultrafoot -> Behringer ---> FCB-1010 Synthesizer -> Roland ---> JV-80 ---> JV-1080 And we could even, someday, do multiple levels of types: MIDI Controller -> Foot Controllers -> Keyboard Controllers -> Control Surfaces Synthesizer -> Keyboard Synthesizer -> Rackmount Synthesizer Drum Units -> Drum Machines -> Drum Modules/Brains However, I'm getting a little too far ahead. I don't want to scare = anybody. I just want to open everyone's eyes to the ultimate = possibilities. What I'd like to see first, is for us to pick the = "low-hanging fruit"... which is just getting the manufacturer/model = JList going. - Joe |
From: Joe E. <jo...@em...> - 2005-02-26 12:13:19
|
Okay... well I made the synth selection window into a JTree. The code is *ugly* (mostly because DevicesConfig needs a major overhaul). In fact, I wasn't expecting it to even *work* the way it is. I was just doing a test to see how close I was getting and, pow, there it went. Give it a try and see if it works for you (I hope Brian already branched the 2.0 candidate...). I know that selecting the Emu throws an exception on mine, but I think that's a bug in some other code. - Joe |
From: Hiroo H. <hir...@co...> - 2005-02-26 14:49:19
|
Joe, Your tool should have a way to know which CVS tags exist. Brian has not create the CVS tag for 0.20 yet. Please revert your change. If you cannot wait for Brian to create the tag, you can create the tag. The thread "How to create a release" starting Aug. 1st, 2004 might help you. Thanks. Joe> Okay... well I made the synth selection window into a JTree. Joe> Joe> The code is *ugly* (mostly because DevicesConfig needs a major Joe> overhaul). In fact, I wasn't expecting it to even *work* the way it is. Joe> I was just doing a test to see how close I was getting and, pow, there Joe> it went. Joe> Joe> Give it a try and see if it works for you (I hope Brian already branched Joe> the 2.0 candidate...). I know that selecting the Emu throws an exception Joe> on mine, but I think that's a bug in some other code. -- Hiroo Hayashi |
From: Joe E. <jo...@em...> - 2005-02-27 01:08:51
|
Hiroo Hayashi wrote: >Joe, > >Your tool should have a way to know which CVS tags exist. > True, but CVS is so complicated that I wasn't sure if IDEA was just hiding the tags from me because it wasn't the version that I had checked out. >Please revert your change. > Okay. I'll have to do that tonight. However, how much do you want me to revert? I added a method to DevicesConfig which is not used by anything else except my new JTree, so I don't see the harm in leaving it there since it'll be unused by anything once I put the original JList back in place of the JTree. Also, If I could (I almost did this anyway last night), I'd prefer to put the whole building and management of the JTree into its own class ("DeviceTree", for example). Then, I can still work on it, but it won't cause any problems because, again, nothing will actually *using* it. In short, there'd be unused code in the CVS tree in *anticipation* of future revisions. Would that be okay, or would you rather not have any of the unused code there at all? >If you cannot wait for Brian to create the >tag, you can create the tag. > Well, that would make me feel a little selfish... forking the code just because I want my stuff included *now*. I don't mind reverting my changes, but it would be nice if I could leave some of the stuff *in* but *unused* so that I don't have to keep the work I've currently done in some text file on my desktop until it's safe for me to paste them into the source again. - Joe |
From: Hiroo H. <hir...@co...> - 2005-02-27 04:57:04
|
Hi, Joe> >Please revert your change. Joe> > Joe> Okay. I'll have to do that tonight. However, how much do you want me to Joe> revert? I added a method to DevicesConfig which is not used by anything I want you to revert all non-bug fix changes. But I'm just one of developers. It's up-to you. Of course revert the change which has a bug at least :-) Brian, I've been waiting for you to create a branch tag. I have pretty much JSLFrame related change. Shall I create a tag after Joe revert the change? -- Hiroo Hayashi |
From: Joe E. <jo...@em...> - 2005-02-27 12:19:32
|
Hiroo Hayashi wrote: >Joe> Okay. I'll have to do that tonight. However, how much do you want me to >Joe> revert? I added a method to DevicesConfig which is not used by anything > >I want you to revert all non-bug fix changes. But I'm just one of >developers. > Well, for the last two years, I've been watching the cvs mailing list, and it definitely appears that you're doing a vast majority of the commits, so I'd definitely consider you to be the *main* developer at this point in time. >It's up-to you. Of course revert the change which has a bug >at least :-) > > Well, I *think* I may have reverted it. IDEA tells me that the cvs commit failed, but I checked out DeviceAddDialog and DevicesConfig again and they look like the old versions. Try an update and see if it's back to a JList.... and make sure the Emu driver adds without an exception again. - Joe |
From: Joe E. <jo...@em...> - 2005-02-28 22:47:02
Attachments:
smime.p7s
|
Now that (I *think*) my JTree changes were reverted, I'll mention some of the other changes I thought of when I was implementing it. ------------ Cleaning up DeviceListWriter and DevicesConfig Right now, DeviceListWriter *writes* the synthdrivers.properties file while DevicesConfig *reads* it. This isn't very good encapsulation. One class should handle all management of the file. This should be either DevicesConfig or a new class. DeviceListWriter is only needed for it's static main() class so that users can force a scan of the synthdriver directories to generate a new synthdriver.properties file, so that's all it should really do: scan directories and then request that DevicesConfig save the new settings to a file. ------------ Further cleaning of DevicesConfig DevicesConfig currently tracks the classname, drivername, IDstring, etc. all in separate hashtables mapping each string to the classname. So, to find the IDstring by drivername (like "AccessVirus"), it has to go to the drivername hashtable, look up the classname for that driver. Then, go to the IDstring hashtable and find the key that points to that class in *that* hashtable. This has two problems. First, it's a little disorganized and inefficient. Secondly (and more importantly) is that this will lead to problems if we ever have a single class that drives multiple devices (like a V-Amp, a Bass V-Amp, and a V-Amp 2). In a case like that, multiple keys in the IDstring/drivername hashtables would have the same class... and trying to look up a key based upon a value in the hashtable will yield unpredictable results. The remedy I propose is to make a class called something like "DeviceDescriptor" which would house all of the important info about a device (name, classname, manufacturer, type, IDstring, etc.) and then have DevicesConfig maintain an array or vector of these descriptor objects. Provided that I *wait* until the 0.2 release is branched/tagged before doing this, does anybody have any other objections to this? - Joe |
From: Rib R. <ri...@gm...> - 2005-02-28 23:52:26
|
That sounds like a great idea. Much better than the hack I put in for the XML driver (since all XML drivers are instaces of the same class). On Mon, 28 Feb 2005 14:51:46 -0800, Joe Emenaker <jo...@em...> wrote: > Now that (I *think*) my JTree changes were reverted, I'll mention some > of the other changes I thought of when I was implementing it. > > ------------ > Cleaning up DeviceListWriter and DevicesConfig > > Right now, DeviceListWriter *writes* the synthdrivers.properties file > while DevicesConfig *reads* it. This isn't very good encapsulation. One > class should handle all management of the file. This should be either > DevicesConfig or a new class. DeviceListWriter is only needed for it's > static main() class so that users can force a scan of the synthdriver > directories to generate a new synthdriver.properties file, so that's all > it should really do: scan directories and then request that > DevicesConfig save the new settings to a file. > > ------------ > Further cleaning of DevicesConfig > > DevicesConfig currently tracks the classname, drivername, IDstring, etc. > all in separate hashtables mapping each string to the classname. So, to > find the IDstring by drivername (like "AccessVirus"), it has to go to > the drivername hashtable, look up the classname for that driver. Then, > go to the IDstring hashtable and find the key that points to that class > in *that* hashtable. > > This has two problems. First, it's a little disorganized and > inefficient. Secondly (and more importantly) is that this will lead to > problems if we ever have a single class that drives multiple devices > (like a V-Amp, a Bass V-Amp, and a V-Amp 2). In a case like that, > multiple keys in the IDstring/drivername hashtables would have the same > class... and trying to look up a key based upon a value in the hashtable > will yield unpredictable results. > > The remedy I propose is to make a class called something like > "DeviceDescriptor" which would house all of the important info about a > device (name, classname, manufacturer, type, IDstring, etc.) and then > have DevicesConfig maintain an array or vector of these descriptor objects. > > Provided that I *wait* until the 0.2 release is branched/tagged before > doing this, does anybody have any other objections to this? > > - Joe > > > |
From: Joe E. <jo...@em...> - 2005-03-01 00:03:22
Attachments:
smime.p7s
|
Rib Rdb wrote: >That sounds like a great idea. Much better than the hack I put in for >the XML driver (since all XML drivers are instaces of the same class). > > At the same time, I intend to rename the methods to proper get/set naming styles... and the names will make more sense. Instead of "deviceNames()", it will be "getDeviceNames" and other lookup things will be named things like "getClassnameByDevicename()" so that it will be easy to know what the method uses as the lookup key. Using IDEA's refactor functions, this should magically adjust any other classes that call it, so it shouldn't break anything. However, if you're currently doing development that interacts with the DevicesConfig class, then this would affect the methods you need to use in the future. - Joe. |