Revising some older code of my I noticed that the function length-divide changed its behaviour somewhat and became more likely to cause an error.
In a previous version, where the arguments count and divide where given separately, it was possible to set the count to some very high number, say, 1000, simply to mean that all notes the function can split (depending on its other arguments) will be split.
Meanwhile, the function have been revised to introduce control over intervals (thank you 🙂), but since then it seems it is not possible anymore to set an arbitrarily high count value anymore. For example, the following code now results in an error. I would prefer the previous behaviour, if only because it is more forgiving and stable.
(length-divide '(1000 2) '(q ab3 num1+leg c4 leg e ab3 leg g3 leg ab3 num1+leg c4 leg)) Error: The value ab3 is not of the expected type sequence.
In case it helps: my debugger tells me the functions gen-repeat and then maybe-section are called (perhaps within a nested function of length-divide* ?) with an argument sequence bound to ab3 (i.e. a plain pitch), and a call (length ab3) then causes this error.
The function LENGTH-DIVIDE and friends are a useful device for introducing some rhythmic variation to some material. However, when the processed sequence is a full OMN expression (see example below), then the added notes cause all other parameters to shift forward (additional parameters are added at the end by looping). For introducing only a slight variation to some existing material (e.g., motif) these functions are therefore not so useful, because this shift of all parameters to basically "fill" the new added notes with pitches etc. greatly change the varied material for a listener.
(length-divide 1 2 '(q f3 leg+m1 q ab3 leg e c4 leg bb3 leg ab3 leg g3))
Basically, this is the opposite situation of the situation addressed by swallowing. Swallowing (e.g., with GEN-SWALLOW and the swallow argument of many other functions) avoids the shift of parameters like pitch etc. that would result from removing notes and turning them into rests. For addressing the situation above properly we would need something like the opposite of swallowing, some way to fill in parameters like pitch etc. for new notes to avoid shifting existing notes. I hope my explanation makes sense and you can see why something like the opposite of swallowing would be useful for functions that add notes to some input material.
Now, the tricky question is of course, what parameters (pitch etc.) should be added in such cases. Musically useful and common in the classical literature would be, e.g., repeating the parameters (pitch etc.) of the predecessor note (though that might be a bit too simplistic and annoying at times) or somehow interpolating some pitch gap between the previous and next note with a little scale or arpeggio and only repeating the other parameters like articulations (resulting in some variation that is likely most similar to the input material, so it would be good to have that as an option). If the pitch interval between the two original notes is too small to add some pitch in between for the new now (or as an option in general for variety), it would also be good to add some ornamentation (e.g., using PITCH-ORNAMENT), but for a close similarity between the original material and the variation it would be best as an option to apply such ornamentation only to the newly added notes, not all notes. Of course, other options could also be useful for variations that vary the input material a bit more strongly, e.g., some random pitch for the new notes within certain interval bounds.
Does some function that kind of is the opposite of GEN-SWALLOW in that it adds parameters like pitches for subdivided rhythmic values (to avoid the shifting) sound like a good idea?
The idea with the interpolation of gaps could be implemented by turning the original duration values and pitches into some envelope and then reading that envelope with the new rhythmic values. So, that is rather strait forward. However, that would not allow for some ornamentation, because such algorithm would not recognise which notes are new that should be ornamented.
Any other idea perhaps? Thanks!