supercollider-quarks/wslib

extVarious-midiname: Array, or would SequenceableCollection be better?

Opened this issue · 2 comments

Array.fillNoteNames
-> [ C3, C#3, D3, Eb3, E3, F3, F#3, G3, G#3, A3, Bb3, B3 ]

List.fillNoteNames
^^ ERROR: Message 'fillNoteNames' not understood.

It seems to me that this might not be an intentional limitation.

Shouldn't these methods be defined on SequenceableCollection?

One peculiar side effect is that Array.fillNoteNames clobbers Array.fill in SC-IDE's auto-completion menu. *fill is defined on Collection, so it ends up lower in the list than the less-frequently-used *fillNoteNames. I believe this would be avoided by defining it higher in the class tree.

Hi James, sorry for the delay, just checking issues now. Yes, makes sense. It would require a bit of rework though, if I just change Array into SequenceableCollection the code "List.fillNoteNames" will render an Array of notenames instead of a list (don't know if that's necessarily a problem but it would seem a bit unclear). Also, I just tried, but it seems that for the completion menu it doesn't make a difference if fillNoteNames is in Array or SequenceableCollection; it still shows up first..

Probably like this:

+ SequenceableCollection {
	*fillNoteNames { arg startNote = "C3", endNote = "B3", step=1;
		// equal to Array.makeScale(type:'chromatic') but probably faster..
		var startNoteMidi = startNote.namemidi;
		^this.series(
			(endNote.namemidi - startNoteMidi + 1) div: step,
			startNoteMidi,
			step
		).collectAs(_.midiname, this)
	}
}

In a class method, using this to invoke the specific subclass is a common pattern. (collectAs is needed because aList.collect produces an array, grrrr.)

Similar could be applied to other methods in the same file.