View Single Post
Old 11-13-2019, 07:15 AM   #5
tack
Human being with feelings
 
tack's Avatar
 
Join Date: Jan 2014
Location: Ontario, Canada
Posts: 1,619
Default

Quote:
Originally Posted by schwa View Post
It doesn't feel right for REAPER to store user information that always has a 1:1 association with data it's already storing.
It was actually this 1:1ness that made me first think of adding it as an attribute to the current custom notation type, since in my use case they would always be coupled.

But I understand your point, especially in the context of bFooz's FR, where there many use cases for general notation userdata unrelated the the current custom notation type. However, IMO it's important to be able to anchor userdata to something the user is able to interact with and move around in the piano roll: for example a note, or track-level notation event.

Let's take a step back to review my specific use-case, where I'm evaluating the idea of using custom notation in Reaticulate instead of program changes.

We have these needs:
  1. Ability to set articulations (read: send keyswitches to patches) for specific notes
  2. Ability to set articulations independent of notes at arbitrary positions
  3. Readable display in the piano roll concisely showing articulation changes
  4. A downstream JSFX processes the articulation change by some numeric identifier, different than what the user sees in the piano roll
  5. Preferably: the user can rename the articulation (e.g. to fix a typo) without the need to scrub the entire project to surgically replace affected events in all MIDI items.

Program changes are actually very nicely suited for this use case. All but the first one are neatly addressed. But it's that first case -- perhaps the most common case for articulation control -- that's very cumbersome today in Reaticulate, especially in light of the current general UX with managing program changes in Reaper.

Another key gap worth addressing is providing better integration with the notation view. (Currently this isn't something Reaticulate tries to do at all.)

The idea being proposed (in one form or another) is to allow Reaticulate to replace program numbers currently used (bank MSB/LSB is immaterial to Reaticulate) with some notation userdata visible to the JSFX for processing both note-specific articulations and general track-level articulations.

I see these challenges:
  1. Lack of machine-friendly user-transparent userdata that could be used to control a JSFX (under discussion here in this thread)
  2. the piano roll view for notation data is clunkier than program changes, as they are prefixed with "custom" (or "articulation"). It'd be nice to be able to hide those prefixes, especially since when you have a several of them close together all you see is the prefixes.
  3. The renaming use case (#5 above) is much trickier with custom notations. Today with program changes, we have Reabanks that map program number to program name and it's easy to edit program names after-the-fact. The number abstracts the program name. Custom notations don't have this indirection. Not impossible to overcome, but a lot more heavy lifting for the script to do.
  4. My proposal here to tie userdata to custom notation types was also compatible with #2 and #3 above. Decoupling userdata from some other existing event that is visible to the user risks that userdata becoming orphaned/desynced.

I don't think it's workable to have hidden, standalone custom notation type for userdata. (I'm not sure if that was actually your thought, schwa, but just in case.) The userdata really does need to be attachable to something the user can directly interact with.

As for the API, I don't have any specific suggestions. I'll need to familiarize myself with the current API for notation.
tack is offline   Reply With Quote