Noob: handling of reserved argument names?

Questions
1

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?

2

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

1 Like
3

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

4 
((
	((
		((
			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
5

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?

6

Not as far as I know, no.

1 Like
7

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
8

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.

9

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})
10

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.