ivanreshe

I recently made an effects rack, using bpatchers of various effects modules I had made, and decided that I needed a way to give the user routing options. So I set out and made my own matrix control (using radiobuttons, so that you can only select one button from each row). Anyway, several hours later I had connected everything up into a 12x12 matrix~, and set up the matrix control to send appropriate messages to set everything up. I hooked up all of the outputs to the top of the matrix and all of the inputs to the bottom of every effects unit. So a simple routing would look like this...

Audio in --> Filter Input --> Filter Output --> Delay Input --> Delay Output --> Audio out

However, there was no sound. I made a simplified version, and realized that if I connected an output of a matrix into the input of an effects unit, then the output of the effects unit back into the input of the matrix, it cuts the sound out completely. Why is this? I have a simple patch here to demonstrate :-

First, copy the delay bpatcher and name it "ireshe.FXDelay", select 'Open in Presentation' from patcher preferences, copy into your patches directory, then run the other file :-

You may need to open it in presentation mode. As you can see, when you connect the audio to go through the delay, then to the output, you have no sound.

If you try deleting the patch cords that connect the delay back into the matrix, and connect the delay into the audio output, then it seems to work. ????? Here is an example of what works (but useless for making a routing system with multiple effects).

Sorry for the lengthy message, but I felt an explanation may help.

If anyone knows what is causing this, and how it can be cured, I would be really grateful.

annoying-problem-using-matrix-to-route-multiple-audio-please-help

Sorry, no need to open the example file in presentation mode...just the delay effect.

On 10 janv. 09, at 12:18, Ivan Redman wrote:

> Sorry for the lengthy message, but I felt an explanation may help.

> If anyone knows what is causing this, and how it can be cured, I 

In your bpatcher there's a case (with gate~ set to 1) where you would 

have a feedback look without delaying it at all (using a tapin~/tapout 

with 0 of feedback, or a send~/receive~). This is not possible because 

you can't work with samples that you didn't get. Adding a tapin~/ 

tapout~ or a send~/receive~ would solve the issue.

> Sorry for the lengthy message, but I felt an explanation may help.
>
> If anyone knows what is causing this, and how it can be cured, I  
> would be really grateful.

In your bpatcher there's a case (with gate~ set to 1) where you would  
have a feedback look without delaying it at all (using a tapin~/tapout  
with 0 of feedback, or a send~/receive~). This is not possible because  
you can't work with samples that you didn't get. Adding a tapin~/ 
tapout~ or a send~/receive~ would solve the issue.

Sorry, I can't say I fully understand what you mean. The gate set to 1 just sends the audio straight out, and having it set to 2 delays the signal then sends it out. The delay bpatcher itself works fine on it's own as far as I have used it, the problem for me is plugging it back into the matrix~. Or have I missed what you are saying?

>> Sorry for the lengthy message, but I felt an explanation may help.

>> If anyone knows what is causing this, and how it can be cured, I

> In your bpatcher there's a case (with gate~ set to 1) where you would

> have a feedback look without delaying it at all (using a tapin~/tapout

> with 0 of feedback, or a send~/receive~). This is not possible because

> you can't work with samples that you didn't get. Adding a tapin~/

> tapout~ or a send~/receive~ would solve the issue.

Yes, MSP is smart enough to see the loops in the audio network and stops

producing sounds. Maybe someday MSP will be even smarter and let you know

about such loops and which objects are involved...

>> Sorry for the lengthy message, but I felt an explanation may help.
>>
>> If anyone knows what is causing this, and how it can be cured, I
>> would be really grateful.
>
>
> In your bpatcher there's a case (with gate~ set to 1) where you would
> have a feedback look without delaying it at all (using a tapin~/tapout
> with 0 of feedback, or a send~/receive~). This is not possible because
> you can't work with samples that you didn't get. Adding a tapin~/
> tapout~ or a send~/receive~ would solve the issue.
>
> ej
>
Yes, MSP is smart enough to see the loops in the audio network and stops
producing sounds. Maybe someday MSP will be even smarter and let you know
about such loops and which objects are involved...
J-F.

I'm afraid I still don't fully understand. The signal chain in the simple example I posted should be like this...

The delay bpatcher works fine, as demonstrated, it is only when it is routed back into the matrix~ that it stops working. I feel that I am missing something here...

Would an alternative be to do the signal chain with multiple selectors~, and route the sound through those, and with send~ and receive~ objects? (thereby not using the matrix at all)

Audio In -->
Matrix Input 1&2 -->
Matrix Output 1&2 (to delay) -->
Delay Input -->
Delay Output -->
Matrix Input 3&4 -->
Matrix Output 3&4 (to audio out) -->
Audio Out

Would an alternative be to do the signal chain with multiple selectors~, and route the sound through those, and with send~ and receive~ objects? (thereby not using the matrix at all)


The problem is routing any of the [matrix~] outputs back into one of its inputs. If you patch in some [receive~] objects to the inputs of your [matrix~] and some [send~]s after your effects this will introduce one vector size of delay and everything should start working. Here is an (empty) example.

Understood, thank you all for your help and patience!

Annoying problem using matrix~ to route multiple audio...Please help!