mixer.pd

But I have errors trying to use it! One of them is that the panner of each channel doesn't work and all channels respond only to panner #1.

Plus the effect channels don't work, and I notice a lot of "multiply defined" errors even though there are no repeated "catch" objects.

Do you have any idea what could be causing these errors?

Here is an abstraction that will give you the [panner] objects........ panner.pd
Put it in the same folder as your patch, then re-open your patch and for each instance give it an argument.
...... so in your patch change each [panner] to [panner 1] [panner 2] etc.....
That will keep them separate..... each one will receive control messages from only the fader that you wish.

Look inside [panner]. You will see at the top [r pan$1]. The $1 will take the argument you have just added to each [panner] as it is created.
Before you continue you should get to grips with abstractions...... that will save you a lot of time as you develop your patches......... https://forum.pdpatchrepo.info/topic/9774/pure-data-noob

You need to change all the hsliders controlling the pan to have a range of 0 to 1
In fact all your sliders need to have a range of 0 to 1 (because audio values in Pd must be in that range) and you will have to change them all in their properties pop up window..
You might well need to reduce the volume after your [catch~] objects as well because adding lots of [throw~] sends together will give you a final output greater than 1.

As @benalb says...... we have no "multiply defined" problems in Pd.
My best guess is that you have opened your patch twice..... effectively having each [catch~] then created twice in the plugdata program.
David.

Ps.... other parts of your patch could also be abstractions...... e.g.

You would create an abstraction...... say [mymix] and give that the argument for the channel number..... [mymix 5] etc.
Inside it would look like this......

..... and [panner $1] would then get the same argument (5 in this case) from its parent abstraction.... its a sort of magic......

And adding a $0 to all the send and receive names would mean that you can open your [mixer] twice without cross communication and without any "multiply defined" errors.
You could even include the control faders and VU's and show them through the GOP window of the abstraction...... another subject, but see the link above.......

Expanding your patch would then be child's play rather than a lengthy process prone to errors.
It's a lot to learn in one hit..... but well worth the effort...

Definitely the abstractions helped a lot... at the beginning I had made them for each channel but I removed them when I saw that they didn't work, I guess I should learn more about them ~ - ~ ''
At that time I hadn't implemented the $1 system in each channel abstraction, that was something I didn't know how to do!

Also I can't believe I forgot to pass my own "panner" abstraction and forgot to connect inlets. I've had this kind of very newbie mistake before, I'm really sorry.

I guess I still have a lot to learn! : 'D

And it might be useful to set your pan faders to 0.5, You can select "init" in their properties, set them all to 0.5, and save the patch. Then they will all be centered when you open the patch again, unless you have changed them. So a better solution is to give them a common receive name.... such as "pan" and send [s pan] a 0.5 triggered by a [loadbang] when the patch is opened.
David.

I have a problem with a mixer.

Have you check the motor brushes?

I'm already far away…