View Single Post
Old 11-12-2019, 02:33 PM   #40
schwa
Administrator
 
schwa's Avatar
 
Join Date: Mar 2007
Location: NY
Posts: 15,750
Default

Quote:
Originally Posted by tack View Post
IReceiving notation MIDI events after note-on means two passes over the incoming MIDI events: one to gather and cache the notation and events, and another to process/route the other events. And not being able to associate custom metadata to notation events (a numeric value specifically) means a lot of string matching would be needed in the JSFX. And I don't see a hash map type structure in EEL (nor would I expect one), which means each mapping an incoming MIDI text event to a Reaticulate articulation is O(n) with respect to the number of articulations on the track.
1. the order of note events and the notation events they own, seems like it should be pretty solvable on the script side, given that the notation event should always be the very next event received after the note-on.

Code:
for (i=1; i <= num_events; ++i)
  if (i < num_events and event[i] is notation) process_note_with_notation(event[i-1], event[i])
  else process(event[i-1])
3. can you suggest how you think the API should look for this? (feel free to direct to another thread)

4. lack of hash map: keeping your list sorted and implementing a basic binary search function would be the usual way to get the performance improvement without adding complexity. This can normally be done with 6-8 lines of code. I just did a quick search and REAPER itself contains at least 21 separate binary search implementations, in addition to at several generic/template implementations in WDL (see WDL_AssocArrayImpl::LowerBound) -- it's almost always easier to just re-implement it in context than to keep making a general implementation more general.
schwa is offline   Reply With Quote