On 23/09/2011 17:04, Joe Emenaker wrote: > On 9/23/2011 6:21 AM, frankster wrote: >> From the docs (which have fallen off the internet in the last couple >> of days!): "The advantage of a scene is that it contains the locations >> for the patches in the synth's memories in addition to the patches >> themselves" So a scene has more to do with a particular synth's setup. >> It does sound useful - though I have to confess I've only really used >> libraries so far. > Ah! I thought scenes were something else. Now that I look at the code, > it is becoming clear to me (and it's also becoming clear that it's coded > improperly... not just in how the GUI's for them look, but in how > they're coded on the back-end). > > Here are my general thoughts on this: > - The "Library" frame is a spreadsheet with the patches and comments, > without any location info. The "Scene" frame is a spreadsheet with the > patches and the bank/patch location on the target synth. But the > spreadsheets look too similar. I'd prefer that the "Scene" spreadsheet > have its rows/columns match the banks/patches on the synth, so we can > drag/drop them around to arrange the patches however we want.
I think there is scope for a synth-level scene and then something to configure ALL synths in one go. Basically a group of scenes (performance?). > - Both the Library and Scene frames allow us to have patches for > different synths in a single window. This strikes me as more confusing > than helpful. I'd prefer to have each Library be limited to just one synth. Yep I agree that we should restrict libraries to one synth. as I comment above, I think we need a mechanism to control the setup of one synth, and a mechanism to control the setup of all synths. This could be achieved either by allowing scenes to hold setups for several synths, or have a new concept of a grouping of scenes. Probably the latter I think, so that would give us 3 concepts. Library, SynthSetup, Performance. > - If we were to have Library frames limited to one synth, then I think > a Library frame should have *all* of the patches for that synth. So, the > DX7 Library frame would have *all* of the patches for a DX7 that JSL > knows of, regardless of where they came from. Because of *that*, you > could make the argument that there's no need to ever have more than one > Library frame for a synth open at one time. You could have multiple > *Scenes* open, and you could be dragging patches from the one Library > window into several different Scenes... but you wouldn't need to have > multiple Library frames for a single synth. Disagree. Firstly libraries with thousands of patches in might be unwieldy. Secondly, it could make it harder to organise sounds. For example, last night I was separating some TX81z sounds so that I could use the "cross breed" functionality on them. I wanted to generate some bass synth sounds and some drum-like sounds. Because of the way cross breed works (randomly off any patch in the library), I found it useful to have a group of drum-like patches in one library, and a group of bas synthy sounds in another library. This way the cross-breed wouldn't attempt to use the shitty "choir" patches in the main library that haven't really stood the test of time, and when I bred drummy sounds with other drummy sounds, the output was more likely to be a drummy sound. That's not to say that we can't have a *view* of all patches for a device. Just as itunes has albums, but might display the individual tracks in a big list. > - The more I think about it, I think of JSL's relationship to synths > as similar to iTunes' relationship to iPhone/iPod, in that iTunes holds > all of your known media, and then some subset of that is synced to your > iPhone or iPod. So, I'm trying to work out some kind of "sync" paradigm I agree with this abstraction/workflow, I think it would be useful and intuitive. > for JSL. For starters, since the Library is holding the computer-side > representation of the patches, it's not limited by the synth's name > limitations, so I think JSL should let us give long names to the patches > in the library. When they're placed into a Scene, then their name either > gets truncated to what the synth's limitation is, or we could maintain a > LongName and a ShortName... who knows? There's no reason we can't add all sorts of tags to patches, such as author, comments, notes, ratings etc. > - Going further with the "sync" notion, we could have JSL deal, in a > smart way, with changed patches it sees from the synth. For example, > suppose I've got a patch called "Swoopy" in my library, and I send it to > my synth. Then, I modify the patch on the synth (during a performance, > say). And then, afterward, I sync a Scene with my synth and JSL would > notice that there's a patch called "Swoopy" on the synth which doesn't > match the "Swoopy" in the Library. I could be given a choice of: 1) > Overwrite the one in the Library, 2) Overwrite the one on the synth, or > 3) Make a new "Swoopy-2" in the library to hold the new one found on the > synth. yep - although in my experience scanning synths entire preset libraries can take a long time, but that doesn't mean it wouldn't be a useful feature albeit with some caveats. frankie ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ Jsynthlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
