Noob: handling of reserved argument names?

Hi, today I ran into an issue again which I fear I might run into again: I used an argument name in a SynthDef that was already reserved by SC for usage with Pattern. The first time was when I used scale, today it was with lag.

These argument names worked fine when I just used a SynthDef, but the moment I control the SynthDef via a Pattern, strange things happen.

Please, is there is a list of keywords which should not be used as argument names? Or is there a best naming practice how to not run into such situations in the first place?

The reserved keys for Event type “note” are described in Pattern Guide 08: Event Types and Parameters | SuperCollider 3.12.0 Help and Event | SuperCollider 3.12.0 Help (toward the bottom, under “Useful Keys for Notes”), and of course the authoritative source is the implementation of Event itself.

1 Like

Thank you! Outside the Pattern/Event realm, are there any other reserved keywords I should not use as SynthDef arguments?

((
	((
		((
			Event.partialEvents.collect(_.keys(Array)).asArray.flat
		)
		++
		(
			Event.parentEvents.collect(_.keys(Array)).asArray.flat
		))
		
		as: IdentitySet
	))
	
	as: SortedList
))

.printAll

// Event.parentEvents.at(\synthEvent).keys(SortedList).printAll
3 Likes

Thank you!

Risking to belabour a potentially moot point, but as two members reacted with answers about pattern/event keywords, am I correct in reasoning that there simply are no keywords in SC areas outside of pattern/event that could give odd results when used as arguments in a SynthDef?

Not as far as I know, no.

1 Like

To be formally correct: Whichever framework you’re using defines “reserved” keywords.

If you’re using patterns + events, then you’re subject to defaults defined in the default event prototype (unless you’re using a different event prototype – I don’t think anyone has defined an alternate event prototype, so you can fairly safely assume that the default event prototype applies – but it is in principle possible to declare a totally different event system, and when using it, the “reserved keywords” would be different).

If you’re using a framework other than patterns/events, then that framework decides what is reserved (e.g. JITLib reserves ‘out’ and ‘gate’ for itself).

hjh

1 Like

This will list all keys and it’s default values on a playable events. The second one is more interesting.

().play.keys.asList.sort.do({|k| (k ++ " = " ++ a[k]).postln})
().play.parent.keys.asList.sort.do({|k| (k ++ " = " ++ a[k]).postln})

But obviously the source of Event is the ultimate source of truth.

This code throws an error for me. Not sure what you were after with list order and indexing, but a simplified the do message function works:

().play.keys.asList.sort.do({|k| k.postln})
().play.parent.keys.asList.sort.do({|k| k.postln})

Oh I’m sort of dumb, so I had ‘a’ set to the default event a = ().play. You need to play an event because that is the method which sets the parent, and those lines iterate through it’s keys and prints the key value pairs.