This is an example of the constant annoyances that occur .
Analysing this synthdef gives an error because it does not recognize the argument name for bus:output.
Yesterday it worked because I posted it in this verry thread ., the code is correct
In short, you would probably like to put effects at the end of the chain with: Synth(\reverbah, \addAction: addToTail);
or Synth.tail(s, \reverbah);
and your source synths at the start of the chain with: Synth(\player, \addAction: addToHead);
or: Synth.head(s, \player);
The code is correct it just doesn’t like Out.ar first argument ,bus:output (output is a declared argument)
Change the Out.ar first argument to 0 and will work , or delete bus:
This all feels verry buggy
It’s like all of a sudden a filter wouldnt’ work because you explicitly wrote freq:1000 in it’s arguments .
Once you put in one keyword argument (bus:), then all arguments after that must have keywords. This is because keyword addressing of arguments may alter the order of arguments, so after that, the only way to be sure which one you mean is to write all the keywords.
I’d suggest simply to leave out the keywords here. Out isn’t a complex UGen; it won’t impair readability to omit the names.
It is definitely not a bug.
I kinda think they are constant annoyances because you’re trying every possible permutation, seemingly randomly, which raises the probability of stumbling onto invalid combinations. I think, if you’re starting from a valid model and then changing stuff to see what happens, it’s necessary to accept that many of these evolutionary mutations will simply not work out.
I see about the placeholders , I sometimes use them and never run into that .
I don’t try stuff at random , the goal is to comprehend the bus routing and by doing so I run into problems which may relate to something completly different .
Everyone is using supercollider in different ways , granted that it might not seem verry methodological by just cherry picking the parts I want to learn .
I am verry close to throwing in the towel ( for the second time ) and just stick to sequencing synthdefs from hardware , but even then the knowledge of buss routing is fundamental .
I know about the basic stuff (started two years ago and and held on for a couple of months ) , made some great synthdefs etc…so the use of variables inside a dsp-synth context where there is a clear signal flow is nothing new and was pretty easy to grasp .
It’s just reaktor or max without wires ( I am purely talking about the audio generating stuff )
The real challenge is to incorpate this into the bigger picture .
Do I just want to use the stepsequencers , do I want to make complete pieces etc…still thinking about what exactly I want to do .
The sequencing and synthdef creation is going fine
My opinion is, fwiw, that SC’s built in bus routing objects are too low level to be pleasant for normal usage. It’s possible to do mixing with them, but you have to rebuild architecture in various places. And it’s too easy to forget to include the bus and group objects in patterns. Too many ways to get it wrong.
For these reasons, I wrote a MixerChannel class (to avoid repeating architecture, and to support DAW-like signal routing, including sends), and a wrapper class for patterns that “binds” a pattern to resources upon which it depends.
Delegating routing to helper objects has made it all a lot easier for me.
I was often making this mistake and couldn’t understand the error. Lost hours being confused.
when using keywords in an argument list, like SinOsc.ar(freq:500,mul:0.5), in that list you can mix and match only in one direction - once you use a keyword, you cannot use an argument without a keyword after it:
// keywords example:
{ SinOsc.ar(freq:555, phase:0, mul:0.5) }.play
// example without keywords in argument list:
{ SinOsc.ar(555, 0, 0.5) }.play
// this is OK:
{ SinOsc.ar(555, mul:0.5) }.play
// this will throw an error
{ SinOsc.ar(freq:555, 0, 0.5) }.play
(edited)
It gets easier after some time. After months of regular work with SC you make less mistakes, you know more by heart, there’s then almost a muscle memory - it’s because you made the same mistake many times in short time so you remembered well enough to not make it more. It’s called learning. We all learn differently - some are faster, some of us are slower. I have found that persistence and regularity have been key in my progress. If I was playing around in SC for few days and then nothing for a month, two or three, I forgot a lot. But if I worked everyday a little, I remember more. Just my experience, maybe it helps you to know that some of us have gone through similar frustrations of making mistakes and not finding where we made the mistake. (some of my posts on this forum are a testament to that).
