Menu
▾
▴
jsynthlib-devel
|
From: Joe E. <jo...@em...> - 2011-09-20 01:40:13
|
On 9/19/2011 6:08 PM, fra...@us... wrote: > fixed crash which can occur at startup when less midi devices are installed than when prefs were saved. > > The problem was that the midi device is stored in the prefs as an integer. When the prefs are loaded, the device number is loaded and no checks are performed causing an array out of bounds exception if you now have less devices than the device number you had previously configured. > > This also caused a problem that the configured devices could change if you plugged in or unplugged a usb device that wasn't even used by JSL, as the correct device would now be in a different position in the array. Given that USB midi devices are probably a lot more common now than 10 years ago, its probably quite common now that available devices might vary from session to session. > > I have changed it so that the midi device is stored as a string (using vladimir's de-duplicated name). When JSL is re-started, as long as the same device name exists, it will be configured correctly regardless of where the device appears in the array. Actually, I already was planning on doing that in the refactor, so you probably saved me some work. Saving the interfaces by name will be much more reliable. While you're in that zone, consider this. In the refactor, the new MIDI code is going to be able to listen on *all* available input ports at once, so the current MIDI configuration panel (where you select a single input and single output port) is going to need to be altered a bit. I don't know if we want to let the user select which portS they want JSL to listen on, or do we want JSL to just listen to everything available all the time? - Joe |
|
From: Frankie F. <jsy...@te...> - 2011-09-20 07:40:59
|
On 20/09/2011 02:40, Joe Emenaker wrote: > While you're in that zone, consider this. In the refactor, the new MIDI > code is going to be able to listen on *all* available input ports at > once, so the current MIDI configuration panel (where you select a single > input and single output port) is going to need to be altered a bit. > > I don't know if we want to let the user select which portS they want JSL > to listen on, or do we want JSL to just listen to everything available > all the time? > > off the top of my head, the only time i can think of where it would be an advantage not to be using all ports is in the "autoscan" functionality because it takes a while to scan each port. Having said that there's no reason why we couldn't scan on all ports in parallel. Maybe there would be some situation where another app could be sending/receiving sysex so maybe we would want to exclude some ports. Maybe we should have an interface like midi-ox where we can multiple select all the ports we want to use franie |
|
From: Joe E. <jo...@em...> - 2011-09-20 14:13:28
|
On 9/20/2011 12:40 AM, Frankie Fisher wrote: > off the top of my head, the only time i can think of where it would be > an advantage not to be using all ports is in the "autoscan" > functionality because it takes a while to scan each port. Keep in mind that I'm talking about the MIDI layer *listening* on all input ports. What this means is: 1 - Drivers still need to decide which port to send *out* on, and 2 - *Drivers* actually (currently) need to decide which port to listen on. Basically, the initial thing that we'll be able to do when the underlying MIDI layer listens on everything is to be able to plug a synth into any MIDI input port, send a sysex dump, and JSL will notice it and be able to bring up a pop-up asking the user what to do about it (save it as a Generic patch, search for a driver for it, assign an existing driver to that new input port, discard it, etc.) > Having said that there's no reason why we couldn't scan on all ports > in parallel. Maybe there would be some situation where another app > could be sending/receiving sysex so maybe we would want to exclude > some ports. Maybe we should have an interface like midi-ox where we > can multiple select all the ports we want to use That's what I was thinking. Initially, it'll be easier to just listen on everything and figure out what nifty features that enables for us. Then, we can put in the config stuff where the user can select individual ports. I think the toughest part is deciding how JSL should respond when *some* of the selected interfaces go missing. Suppose I have two USB MIDI interfaces, and I have some drivers using ports on each one. Then, I remove one of the MIDI interfaces and then run JSL again. Should JSL re-query the user about: 1 - Which ports to listen on? 2 - The port assignments for every driver which had its port go missing? or do we want to just have JSL fail-over to a default port? If we just give the user a default, what do we do if that interface shows back up again, later? - Joe |
|
From: Frankie F. <jsy...@te...> - 2011-09-20 17:45:51
|
On 20/09/2011 15:13, Joe Emenaker wrote: > > I think the toughest part is deciding how JSL should respond when *some* > of the selected interfaces go missing. Suppose I have two USB MIDI > interfaces, and I have some drivers using ports on each one. Then, I > remove one of the MIDI interfaces and then run JSL again. Should JSL > re-query the user about: > 1 - Which ports to listen on? > 2 - The port assignments for every driver which had its port go missing? > or do we want to just have JSL fail-over to a default port? > > If we just give the user a default, what do we do if that interface > shows back up again, later? Yep this is a problem that came up when I fixed the issue with midi ports last night. If you have a synth connected to USB interface X which is disconnected, before it would either end up on a random interface or crash, whereas now it will fail to load that interface and instead connect to whichever interface happens to be in position 0. I think this then gets saved at some point so if you start it up again but this time the interface is there, you will remain on whichever interface was at 0 the previous time. I think rather than fall back to a default port the better outcome would be that it retains the interface the user set it at and the interface could be marked as unavailable in any lists that are displayed. Possibly re-query the user or maybe just warn them that the port is not available. It would depend if its a common use case to disconnect and reconnect ports, and if constant re-querying is a pain in the arse or not! frankie |
|
From: William Z. <wrz...@po...> - 2011-09-20 19:43:27
|
On Tue, Sep 20, 2011 at 10:45 AM, Frankie Fisher < jsy...@te...> wrote: > > .. constant re-querying is a pain in the arse .. > How about this: jsl only saves a list of which ports were DISabled, by name. (There's a unique name string for each port, isn't there?) I think this supports the use cases mentioned above -- jsl picks up all ports with about spamming user, but hides the ports the user doesn't want jsl to manage. I also believe that jsl should be port-agnostic -- if a synth moves to another port, jsl should assume it's the same synth and not bother the user. But there's another problem (maybe) -- what if the user has two copies of the same synth? Is that even a problem? On a related note, I've never liked the GUI. When I first started using jsl, I expected something more like Windows Explorer 2-pane view, which shows folders on the left and files on the right. In this case, the left pane would show ports, and under each port would be the synths on that port. Ports blocked by the user would still appear, but greyed out. -Bill Zwicky |
|
From: Joe E. <jo...@em...> - 2011-09-20 19:57:39
|
On 9/20/2011 12:42 PM, William Zwicky wrote: > How about this: jsl only saves a list of which ports were DISabled, by > name. That's exactly what I was going to suggest. > I also believe that jsl should be port-agnostic -- if a synth moves to > another port, jsl should assume it's the same synth and not bother the > user. But there's another problem (maybe) -- what if the user has two > copies of the same synth? Is that even a problem? It could be. What if I want different banks on the different synths? What I was thinking is that, if some sysex comes in on a port, and JSL can't find a driver assigned to that port which "claims" that sysex for itself, but there *is* a driver for that sysex assigned to a *different* port, then JSL could ask "Is this one of your current BFD-100's, or is this a new one?". That kinda deal. > On a related note, I've never liked the GUI. It's horrific. > When I first started using jsl, I expected something more like Windows > Explorer 2-pane view, which shows folders on the left and files on the > right. In this case, the left pane would show ports, and under each > port would be the synths on that port. Ports blocked by the user would > still appear, but greyed out. Actually, I was thinking of either something like Midiquest (http://www.soundquest.org/images/MQ10/MQ10.1280.png) where you have images of the synths, or something like a "desktop", where you've got icons of all of your synths which you can drag around the way you want to look like your studio arrangement. Either way, I think images of the synths would be a nice improvement. - Joe |
){kind=link}
|
From: Frankie F. <jsy...@te...> - 2011-09-20 20:08:50
|
On 20/09/2011 20:42, William Zwicky wrote: > On Tue, Sep 20, 2011 at 10:45 AM, Frankie Fisher < > jsy...@te...> wrote: > >> .. constant re-querying is a pain in the arse .. >> > How about this: jsl only saves a list of which ports were DISabled, by > name. (There's a unique name string for each port, isn't there?) I think > this supports the use cases mentioned above -- jsl picks up all ports with > about spamming user, but hides the ports the user doesn't want jsl to > manage. This would probably work as long as we also have some method of automatically figuring out which port a device is on or if its not connected. would we need to do a device scan (06 01) each time at startup to work out which port a device is on? I know not all devices support this though. > > I also believe that jsl should be port-agnostic -- if a synth moves to > another port, jsl should assume it's the same synth and not bother the > user. But there's another problem (maybe) -- what if the user has two > copies of the same synth? Is that even a problem? Can we assume that duplicate synths will always have a different device id? or are there some devices where this isn't the case? maybe synths that dont support device ids? frankie |
×
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