Re: [Rosegarden-user] SysEx banks? - re-post in plain text, for real

[Andrew S]

Horror of horrors!  Forgot to actually switch to plain text, in previous send.  
I am not good at this, apparently. Profuse apologies.  Will try to get better.

Re-posting previous message in plain text for real this time, as users fed back 
with complaint about it being illegible.



Sorry - it's a little long-winded. Also, I did add a new paragraph here (begins 
with "That's kind of what I meant...")


> On 09/06/2022 8:50 PM EDT david  wrote:





> Hmm, aren't SysExes proprietary, perhaps even undocumented or secret?


I was going to reply off-the-cuff with a "No it's not secret," but decided to 
first google around

So - I poked around some sites discussing SysEx's. Did not find anything that 
suggests "secret".

Looked at my Korg Kross Parameter Guide again -- in particular the Appendices 
at the end, with system exclusive codes... five pages.

Found a downloadable PDF for Korg Kronos -- which has its SysEx specs, too. 
Found some Roland SysEx listings, as well as Alesis (didn't search 
exhaustively). Indications are - no, this info is not at all secret and not 
undocumented. Major brands provide it in their product's user manuals

(It *is*, most definitely, "proprietary" - ... For example: For some Roland 
synth model there might not even be a control parameter that exists in some 
Korg model)


> Perhaps a tool for the user to create their own SysEx specific to their 
> hardware?


That's kind of what I meant. I actually first thought of exactly as you 
formulate above, but then expanded it to "banks" - because those are bundled 
with the distribution and shared... (instrument banks are shared, saving people 
time redundantly building the mappings for specific synths models)


> I don't know anything really about SysExes, just going on a vague 
> recollection about them being proprietary.


Here's my guess: linguistically speaking - I am theorizing that the word 
"exclusive" in "system exclusive" might have been a hasty/sloppy choice of 
words that stuck (don't know who actually coined the term). And caused 
confusion -- including the false perception that the info is off limits to the 
general consumer base

Perhaps the better term would have been "system-specific" ... ?

Because (willing to bet two six packs) - in some rare cases, the codes are 
probably not exclusive either, but are actually shared. Out of a sea of synth 
models there are probably some two different models, of two different makes, 
for which some volume or effect control is the same code. At least there is no 
explicit policy (my guess) or engineering constraint that would prevent this. 
Which would bust up the notion that that code is "exclusive" to a make and/or 
models.


So... if the developers were to add SysEx banks, similar to the instrument 
banks, and the feature got usage traction, it would be like porting in and 
concentrating SysEx data scattered about various User manuals, into one 
unifying library that cuts across makes and models... as well as creating 
uniformity and top-level observation point for system exclusive data... yada 
yada, etc, etc. Might even be an original, unprecedented thing and snowball 
(?)... boosting the app-user creative feedback loop... As in... a Rosegarden 
user would be quickly oriented about SysEx possibilities, with the availability 
of such a bank... Might even, no doubt, impact further hardware purchase 
decisions : - ))). Might slightly shift production focus away from virtual 
synths and plugins to external hardware... guessing the trend these days is to 
move the other way... (away from external hardware to plugins)



If I have all my synth's SysEx control codes neatly organized and coherently 
LABELED, in a Rosegarden bank, and can easily drag and drop one into my tracks 
they might be more likely to be a part of the project... 
Awareness->availability->demand cycle (yada yada)... might snowball.


___
Rosegarden-user mailing list
Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-user

Re: [Rosegarden-user] SysEx banks? - re-post in plain text

[Andrew S]

 
 
   


 Re-posting previous message in plain text.
 
 

 Sorry - it's a little long-winded.  Also, I did add a new paragraph here (begins with "That's kind of what I meant...")
 

   
 

   
(... thought I sent this to the list yesterday, but only sent to an individual.  By the way - messages on this list often take *hours* to propagate)

   
 

   
 

 On 09/06/2022 8:50 PM EDT david  wrote:
 
 

 
 
 
 
 
  Hmm, aren't SysExes proprietary, perhaps even undocumented or secret?
  
 
 

 I was going to reply off-the-cuff with a "No it's not secret,"  but decided to first google around  
 

  
 

 So - I poked around some sites discussing SysEx's.   Did not find anything that suggests "secret".
 

  
 

 Looked at my Korg Kross Parameter Guide again -- in particular the Appendices at the end, with system exclusive codes...  five pages.
 

  
 

 Found a downloadable PDF for Korg Kronos -- which has its SysEx specs, too.  Found some Roland SysEx listings, as well as Alesis (didn't search exhaustively).   Indications are - no, this info is not at all secret and not undocumented.  Major brands provide it in their product's user manuals
 

  
 

  (It *is*, most definitely, "proprietary" - ... For example: For some Roland synth model there might not even be a control parameter that exists in some Korg model)
 
 
 
 
  Perhaps a tool for the user to create their own SysEx specific to their hardware?
  
 
 

 That's kind of what I meant. I actually first thought of exactly as you formulate above, but then expanded it to "banks" - because those are bundled with the distribution and shared... (instrument banks are shared, saving people time redundantly building the mappings for specific synths models)
 
 
 
 
  I don't know anything really about SysExes, just going on a vague recollection about them being proprietary.
  
 
 

  Here's my guess:  linguistically speaking - I am theorizing that the word "exclusive" in "system exclusive" might have been a hasty/sloppy choice of words that stuck (don't know who actually coined the term).  And caused confusion -- including the false perception that the info is off limits to the general consumer base
 

  
 

 Perhaps the better term would have been "system-specific" ... ?
 

  
 

 Because (willing to bet two six packs) - in some rare cases, the codes are probably not exclusive either, but are actually shared.   Out of a sea of synth models there are probably some two different models, of two different makes, for which some volume or effect control is the same code.   At least there is no explicit policy (my guess) or engineering constraint that would prevent this.  Which would bust up the notion that that code is "exclusive" to a make and/or models.
 
 

 So... if the developers were to add SysEx banks, similar to the instrument banks, and the feature got usage traction, it would be like porting in and concentrating SysEx data scattered about various User manuals, into one unifying library that cuts across makes and models... as well as creating uniformity and top-level observation point for system exclusive data... yada yada, etc, etc. Might even be an original, unprecedented thing and snowball (?)... boosting the app-user creative feedback loop... As in... a Rosegarden user would be quickly oriented about SysEx possibilities, with the availability of such a bank... Might even, no doubt, impact further hardware purchase decisions : - ))). Might slightly shift production focus away from virtual synths and plugins to external hardware... guessing the trend these days is to move the other way... (away from external hardware to plugins)
 
 

  
 If I have all my synth's SysEx control codes neatly organized and coherently LABELED, in a Rosegarden bank, and can easily drag and drop one into my tracks they might be more likely to be a part of the project...   Awareness->availability->demand cycle (yada yada)... might snowball.

  
 


___
Rosegarden-user mailing list
Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-user

[Rosegarden-user] Posting etiquette (Was Re: SysEx banks? - Errata)

[Andrew S]

> On 09/07/2022 10:58 AM EDT rhkra...@gmail.com wrote:
> 
> 
> This is the beginning of what I see in a text only client -- didn't bother to
> copy the whole thing...

I will be sticking to plain text then.  Wasn't sure before, if formatted text 
has become acceptable here. 
 
> If you reply: snip, snip, and snip again; leave attributions; avoid HTML;

Good idea.  I was previously concerned about including more context for 
potential newcomer readers... But I guess one can always read previous messages 
in the thread -- that's what threads are for (to the tune of "..that's what 
friends are for")

> avoid top posting; and keep it "on list". (Oxford comma included at no

I used to religiously quote and post at the bottom (avoid top posting).  But 
then landed in a corporate environment where all of the (hundreds) of my 
coworkers had **absolutely no clue** about bottom posting, and had no notion of 
"top posting" and why that's a bad thing.

Plus, our corporate mail client of choice (Outlook) has done everything 
possible to make quote/bottom posting a skull-numbing exercise.

I will quote-post here.

> charge.) If you change topics, change the Subject: line.
> 
> Writing is often meant for others to read and understand (legal agreements 
> excepted?) -- make it easier for your reader by various means, including

writing in forums and mailing lists is *always* meant for others to read.

> liberal use of whitespace and minimal use of (obscure?) jargon, abbreviations,
> acronyms, and references.
> 
> If someone else has already responded to a question, decide whether any
> response you add will be helpful or not ...
> 
> A picture is worth a thousand words -- divide by 10 for each minute of video

The above tip itself is not coherently phrased.  Attaching videos/stills is 
bad? Or preferred? Divide what by 10, exactly?  Video play time? Either way - 
sounds like a contrived metric that's not always applicable... videos come in 
vastly varying quality and levels of informativeness.  

Also, there is a 40k limit on attachments in this mailing list (as I mentioned 
recently in another thread). This limit provides little to no opportunity to 
attach good resolution still images, let alone videos.


___
Rosegarden-user mailing list
Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-user

Re: [Rosegarden-user] SysEx banks? - Errata

[Andrew S]

 
 
  
   Apologies... looked over what I sent and found so many typos that my text might be bordering on incoherence in places.  So decided it was worth sending an errata.  I highlighted the correcting words in bold, red and all caps.  (I guess on text-only clients you'd only see the all-caps).
   
  
    
   
  
   (wrote a draft last night, practically falling asleep on the couch, didn't comb through it enough before sending)
   
  
    
   
   
   
On 09/07/2022 8:30 AM EDT Andrew S  wrote:

   
 

   
Found a downloadable PDF for Korg Kronos -- which has its SysEx specs, too.  Found some Roland SysEx listings, as well as Alesis (didn't search exhaustively).   Indications are - no, this info is not at all secret and not undocumented.  Major brands provide it in their product's user manuals

   
 

   
(It *is*, most definitely, "proprietary" - ... For example: some Roland synth mode there might not even have  a control parameter that might exist in a Korg)

   
 

   
 

   
  
    
   
   
   
(It *is*, most definitely, "proprietary" - ... For example: FOR some Roland synth modeL THERE might not even BE a control parameter that exists in SOME Korg MODEL)

   
 

   
   
   
So... if the developers were to add SysEx banks, similar to the instrument banks, and they got usage traction, it would be like porting in and concentrating SysEx data scattered about various User manuals, into one uniform library that cuts across makes and models... (But! at the same time creates uniformity and top-level observation point for system exclusive data... yada yada, etc, etc).  Might even be an original, and unprecedented (?)... and snowball... with a creative feedback loop... As in... a Rosegarden would be quickly oriented about SysEx possibilities, with the availability of such a bank...   Might even, no doubt, impact further hardware purchase decisions : - ))).   Might slightly shift production focus away from virtual synths and plugins to external hardware... guessing the trend these days is to move the other way... (away from external hardware to plugins

   
  
    
   
   
   
 

   
So... if the developers were to add SysEx banks, similar to the instrument banks, and THE FEATURE got usage traction, it would be like porting in and concentrating SysEx data scattered about various User manuals, into one UNIFYING library that cuts across makes and models... AS WELL AS creating uniformity and top-level observation point for system exclusive data... yada yada, etc, etc. Might even be an original, unprecedented THING and snowball (?)... BOOSTING THE APP-USER creative feedback loop... As in... a Rosegarden USER would be quickly oriented about SysEx possibilities, with the availability of such a bank... Might even, no doubt, impact further hardware purchase decisions : - ))). Might slightly shift production focus away from virtual synths and plugins to external hardware... guessing the trend these days is to move the other way... (away from external hardware to plugins)

  
 


___
Rosegarden-user mailing list
Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-user

Re: [Rosegarden-user] SysEx banks?

[Andrew S]

 
 
  
    
   
   
   
On 09/06/2022 8:50 PM EDT david  wrote:

   
 

   
 

   
On 9/6/22 10:50, Andrew S wrote:



 Just occurred to me - Rosegarden could have SysEx banks, similar in structure, XML storage,  and UI widgetry, to the instrument banks it already has.
 

  
 

 They would be similarly defined per synth make & model ... and similarly bundled with the app and shared, with the distributed list gradually growing.
 

  
 

 (Probably a bit less work to add as a feature than the drag-move event band I posted about earlier today?)
 

  
 

   Hmm, aren't SysExes proprietary, perhaps even undocumented or secret? 
   
  
    
   
  
   I was going to reply off-the-cuff with a "No it's not secret,"  but decided to first google around  
   
  
    
   
  
   So - I poked around some sites discussing SysEx's.   Did not find anything that suggests "secret".
   
  
    
   
  
   Looked at my Korg Kross Parameter Guide again -- in particular the Appendices at the end, with system exclusive codes...  five pages. 
   
  
    
   
  
   Found a downloadable PDF for Korg Kronos -- which has its SysEx specs, too.  Found some Roland SysEx listings, as well as Alesis (didn't search exhaustively).   Indications are - no, this info is not at all secret and not undocumented.  Major brands provide it in their product's user manuals
   
  
    
   
  
   (It *is*, most definitely, "proprietary" - ... For example: some Roland synth mode there might not even have  a control parameter that might exist in a Korg)
   
  
    
   
  
    
   
   
   
 



 I don't know anything really about SysExes, just going on a vague recollection about them being proprietary.
 

  
 
  

   
 

   
  
   Here's my guess:  linguistically speaking - I am theorizing that the word "exclusive" in "system exclusive" might have been a hasty/sloppy choice of words that stuck (don't know who actually coined the term).  And caused confusion -- including the false perception that the info is off limits to the general consumer base
   
  
    
   
  
   Perhaps the better term would have been "system-specific" ... ?
   
  
    
   
  
   Because,  (willing to bet two six packs) - in some rare cases, the codes are probably not exclusive either, but are actually shared.   Out of a sea of synth models there are probably some two different models, of two different makes, for which some volume or effect control is the same code.   At least there is no explicit policy (my guess) or engineering constraint that would prevent this.  Which would bust up the notion that that code is "exclusive" to a make and/or models.
   
  
    
   
   
   Perhaps a tool for the user to create their own SysEx specific to their hardware? 
   
  
    
   
  
   So... if the developers were to add SysEx banks, similar to the instrument banks, and they got usage traction, it would be like porting in and concentrating SysEx data scattered about various User manuals, into one uniform library that cuts across makes and models... (But! at the same time creates uniformity and top-level observation point for system exclusive data... yada yada, etc, etc).  Might even be an original, and unprecedented (?)... and snowball... with a creative feedback loop... As in... a Rosegarden would be quickly oriented about SysEx possibilities, with the availability of such a bank...   Might even, no doubt, impact further hardware purchase decisions : - ))).   Might slightly shift production focus away from virtual synths and plugins to external hardware... guessing the trend these days is to move the other way... (away from external hardware to plugins)
   
  
    
   
  
   If I have all my synth's SysEx control codes neatly organized and coherently LABELED, in a Rosegarden bank, and can easily drag and drop one into my tracks they might be more likely to be a part of the project...   Awareness->availability->demand cycle (yada yada)... might snowball.
   
  
    
   
  
    
   
  
   -- David W. Jones gn...@hawaii.rr.com authenticity, honesty, community http://dancingtreefrog.com "My password is the last 8 digits of π."___ Rosegarden-user mailing list Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-user
  
 


___
Rosegarden-user mailing list
Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-user

[Rosegarden-user] SysEx banks?

[Andrew S]

 
 
  
   Just occurred to me - Rosegarden could have SysEx banks, similar in structure, XML storage,  and UI widgetry, to the instrument banks it already has.
   
  
    
   
  
   They would be similarly defined per synth make & model ... and similarly bundled with the app and shared, with the distributed list gradually growing.
   
  
    
   
  
   (Probably a bit less work to add as a feature than the drag-move event band I posted about earlier today?)
   
  
    
   
  
    
  
 


___
Rosegarden-user mailing list
Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-user

Re: [Rosegarden-user] Matrix controller quantization?

[Andrew S]

 
 
   
   
Hello, all.

   
 

   
 

   
[technical problems: This is my 5th attempt to post this message. I have two “screenshots”, in JPGs. Auto-reply tells me the size limit here is 40K. You can’t send any meaningful image, especially TWO of them, scaled down to under 40K. My previous 4 attempts are “awaiting moderator approval”. To moderators: Please approve my 3rd attempt – it’s got decent resolution, and has last text edit. Posting without the pics, though referencing them in context]

   
 

   
 

   
I am intrigued and buoyed by this thread. What comes to my mind is a variation on this requested feature, and what i see as a game-changing expansion of Rosegarden.

   
 

   
If the events that are currently viewable and editable only in the event editor become, with this new feature, visualized in a horizontal strip, it would seriously empower and accelerate production. (Correct me if i am wrong.)

   
 

   
I am including a couple of hypothetical, "photo-shopped" screenshots with drawn horizontal timeline strips that align with the existing note event strips -- one in the main view, the other in the notation editor.

   
 

   
I am thinking these could/should be user-creatable, to include certain types of events (using a type filter that currently exists for the event matrix), for starters. (A deluxe version could be separating/grouping events not by event TYPE but just by the very same container I am talking about -- but that might be too radical a code revision at the moment. Essentially, to add user-created events container… primarily for element organization purposes. )

   
 

   
This would yield an awesome event editor, with drag-and-drop-aligning events against note events.

   
 

   
As a side note, I would like to add/remind about SysEx events.To test functionality I added some SysEx events for playback through my Korg hardware.It works! (Rosegarden was turning portamento on and off on my Korg, during the external hardware playback)

   
 

   
But! I had to tediously add my SysEx events mathematically and manually, rather than through the convenience of a drag-move-adjust UI. Would be super-powerful to be able to drag-align, copy-duplicate, cut/copy & paste events along a time strip!(To repeat for emphasis: "a game changer!": - ))

   
 

   


   
 

   
Of course, I think these automation/event strips should be creatable arbitrarily, without limit of number.

   
 

   
 

   
The event strip should also appear in the Notation Editor (even through this would stretch the semantic scope of the current label "NOTATION editor" - the semantic glitch is worth the empowerment this would bring. Maybe one could relabel “notation editor” to something broader)

   
 

   


   
 

   
In the notation editor the events should have a hover tooltip with information about the event, and, as I said above, should be drag-movable/editable, with the vertical hairline appearing on drag-move, and a readout of metrics: measure, tick value, etc., during drag.

   
 

   
I realize that code-wise this would be a hge modification.Probably require creating a polymorphic superclass object that contains (serves as parent class for) BOTH the current note event strip object, and also the new event strip...And then there's the conditional differentiation all over the place, where it is referenced.

   
 

   
But!Perhaps this would be a step in the direction of "legitimate" automation, which Rosegarden is currently missing and which (arguably) currently sets Rosegarden apart from mainstream DAWs.(Please note that I recognize Rosegarden's advantage over these same DAWs -- particularly as a hybrid of both notation options and multi-track, multi-part digital recorder)

   
 

   
Maybe there would be another (relatively) easy step from this toward FULL automation, with curve based real-time parameter envelope, for automated control of any arbitrary parameter...For that, it would then be prudent to do the re-coding I am suggesting, in such a way as to anticipate installation of further automation.(I.e. - not code the above as a binary switch between notation and events, but rather allow for future multiplicity of strip types, beyond the two discussed)

   
 

   
   
   
On 09/04/2022 2:15 PM EDT Lorenzo Sutton  wrote:

   
 

   
 

   
On 03/09/2022 19:16, Ted Felix wrote:



 On 9/2/22 7:26 AM, Lorenzo Sutton wrote:
 
 
 
  I think it would make sense to be able to place controllers in a
  
 
  non-continuous way on the (horizontal) time-scale depending on the
  
 
  selected matrix Grid or quantization.
  

[Rosegarden-user] timeOffset parameter

[Andrew S]

[duplicate message. Sending as plain text this time and also testing list 
subscription]

Greetings

What is the timeOffset parameter for?

In the XML you see it as an attribute of the note event:



My initial guess was that it is a temporal offset, such that a non-zero value 
would shift the start play time by that value (note is played early or late)

Experimenting with changing the value seems to indicate i guessed wrong.

Or perhaps it is only used in the absence of an "absoluteTime" value, with the 
latter overriding the former? (because without an explicit absoluteTime 
rosegarden dynamically computes the actual trigger time, and only then does it 
use the timeOffset value?)

thanks


___
Rosegarden-user mailing list
Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-user

[Rosegarden-user] timeOffset parameter

[Andrew S]

 
 
  
   Greetings
   
  
  
   
  
  
   What is the timeOffset parameter for? 
   
  
  
   
  
  
   In the XML you see it as an attribute of the note event:
   
  
  
   
  
  
   
   
  
  
   
  
  
   My initial guess was that it is a temporal offset, such that a non-zero value would shift the start play time by that value (note is played early or late)
   
  
  
   
  
  
   Experimenting with changing the value seems to indicate i guessed wrong.
   
  
  
   
  
  
   Or perhaps it is only used in the absence of an "absoluteTime" value, with the latter overriding the former? (because without an explicit absoluteTime rosegarden dynamically computes the actual trigger time, and only then does it use the timeOffset value?)
   
  
  
   
  
  
   thanks
   
  
  
   
  
 


___
Rosegarden-user mailing list
Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-user