> On 09/11/2024 8:57 AM EDT Bric <b...@flight.us> wrote: > > > > > > > > > > You'd need to change the note's start position. Given X% swing, > > > you'd need to shift the start of the second eighth note in a pair of > > > swung eighth notes, forward, in time, by (X-50)/50 of its own > > > duration. (E.g., for a swing of 63, the second note shrinks by (63- > > > 50)/50 = 13/50, and shifts forward by that difference. > > > > > > But again. First, denemo needs to identify each pair of eights > > > properly, > > > As you have an insight into the choosing of which pairs of eighth notes > > you would wish to swing I wonder if you would care to implement inside > > Denemo? You would need to familiarise yourself with Scheme, but that is > > not so difficult a very simple syntax, and with the procedures > > available for Denemo such as d-MoveCursorLeft and d-GetNoteDuration. I > > could help with the latter, it would be a question of modifying the > > script for the command SwingStaff which you can inspect from within > > Denemo. > > > > Would love to give it a go! (and, no -- not suggesting we use "Go" :-)) > > I'm not too solid on Scheme but have always been fascinated with it. (Was > able to do a few quick hacks in Scheme here and there) > > Yeah... I've had some success writing a swing rhythm transformation. (The > code did not run in real time, however -- but it probably could). > > Essentially, it first identified the swing pairs, by tracking/evaluating the > start position of every note, within the measure. Not hard. Actually works > for cases where there is no explicit pair(!) -- where the first note of the > pair is theoretical/imaginary -- it applied the transform to the second > (explicit) note of the pair, because that note's position can be computed for > eligibility (without the existence of the first note). Once the eligible > note is identified, the rest should be trivial > > To do the above in Denemo, it would also be easy -- if the function had the > start position parameter. Would it do the transform **ahead** of the > playback? Like - prepping the data first and THEN playing back? Or would it > apply the transform in realtime, as it executes the playback?
Just realized that I already had the answer to that last one, i guess. The color highlighting (in blue) in the editor is evidence that the function is being applied before any playback happens. So, I hope the extra data scan, for swing notes, doesn't add too much overhead to the editor. Maybe let the user choose to have the swing assessment occur as they typed, versus having to manually re-scan and re-assess swing (?) I guess you could store explicit attributes in XML, per note, but that would add some bloat to the doc. (In the <chord></chord> node, (swing="on")) Or you could mark note-level only for passages that are exceptions to what the staff-level XML is set for. (Note-level says swing="off" to except from staff-level "on", and vice versa). Or you could have an "on" switch for "every note from here onward, until further notified (until off)" -- not sure if there's an accommodation for that type of sub-sequence mark-up.
