analord

So I'm trying to make an array of instances of this sample-cutting app I've made, for taking multiple inputs and sending them to any one of 4 cutting bpatchers.

My problem is audio related. To preface, I'm running Windows 7 64bit with an M-Audio Fast Track Pro as an interface (recently updated drivers).

I have an adc~ object with two channels, the two ins on my interface. I then send these individual outputs, via send~, to all 4 instances of the sample-cutter. What oddly happens is that once the signal from send~ is receive~'d, it picks up audio from -both- channels. If I plug my guitar into channel one and send~ it as "one", it still gets picked up within the bpatch'd sample cutting instance even if the receive~ object is set to pick up "two".

I'm thinking this may be an issue with max because I meter'd up the two individual inputs coming from dac~ and they're distinguished from one another fine. It's only when I start using send~ and receive~ within bpatcher do things fuck up.

Any help would be awesome - if you need me to post a clipboard'd version of my patch I can as well.

So I'm trying to make an array of instances of this sample-cutting app I've made, for taking multiple inputs and sending them to any one of 4 cutting bpatchers. 

My problem is audio related. To preface, I'm running Windows 7 64bit with an M-Audio Fast Track Pro as an interface (recently updated drivers). 

I have an adc~ object with two channels, the two ins on my interface. I then send these individual outputs, via send~, to all 4 instances of the sample-cutter. What oddly happens is that once the signal from send~ is receive~'d, it picks up audio from -both- channels. If I plug my guitar into channel one and send~ it as "one", it still gets picked up within the bpatch'd sample cutting instance even if the receive~ object is set to pick up "two". 

I'm thinking this may be an issue with max because I meter'd up the two individual inputs coming from dac~ and they're distinguished from one another fine. It's only when I start using send~ and receive~ within bpatcher do things fuck up. 

Any help would be awesome - if you need me to post a clipboard'd version of my patch I can as well.


problems-w-send-and-receive

It’s only when I start using send~ and receive~ within bpatcher do things fuck up.

How do you name your receive~ into the bpatcher? Using a parameter?

Yeah, with an argument. adc~'s two channels are called chan L and chan R respectively, on both the receive~ and send~ objects. I've tried using "set chan l/r" messages on the receive~ objects as well, no effect.

Names for receive~/send~ pairs should be one symbol only, i.e. 

 (or you need to add quotes, but that's another story). So all your send~ and receive~ use simply 

Then I don't understand why you have bpatchers with 4 different patcher files. You should only use one. If you want to change the 

SOmething like this (have a look at the bpatcher's inspector) should help you:

Names for receive~/send~ pairs should be one symbol only, i.e. chan1 and not chan 1 (or you need to add quotes, but that's another story). So all your send~ and receive~ use simply chan or main and ignore the rest of the arguments.

Then I don't understand why you have bpatchers with 4 different patcher files. You should only use one. If you want to change the receive~ argument, then use #1 and arguments.

Max uses spaces to separate arguments, so as far as it's concerned "send~ main out L" and "send~ main out R" are "send~ main" and "send~ main", since send~ is only looking at the first argument (which is main). Same thing is happening with "chan 1" and "chan 2".

You could wrap the thing in quotes to treat it as a symbol, but I'd recommend avoiding this; it's way more trouble than it's worth in the long run. Instead, just use underscores or camel case (e.g. main_out_L or mainOutL).

The target/destinations for send/send~/receive/receive~ 

 case-sensitive. When I make a receive, I copy and paste it to make the send so I don't accidentally mess up the case. Best practice is to pick a naming convention and stick with it, because this kind of error can be a royal pain to debug.

Other useful thing: you can use an argument at the front of receive names, such as #1_channel, #2_channel. (has to be at the front) This lets you specify the names of the receives using arguments to your bpatcher which will make the whole thing more flexible.

Also, if you want to make local sends and receives, use #0 in front of the name of the receive. In this case it you've got a "s tempo" in each bpatcher, and that's probably causing confusion, since it means that all of the loops are getting reset 4 times. If you use "s #0_tempo" it will create a send that's unique to that bpatcher. The #0 creates a unique 4 digit id on load that is specific to that patcher, so your sends would look something like 1001_tempo, 1002_tempo, 1003_tempo, 1004_tempo.

Max uses spaces to separate arguments, so as far as it's concerned "send~ main out L" and "send~ main out R" are "send~ main" and "send~ main", since send~ is only looking at the first argument (which is main).  Same thing is happening with "chan 1" and "chan 2".

You could wrap the thing in quotes to treat it as a symbol, but I'd recommend avoiding this; it's way more trouble than it's worth in the long run.  Instead, just use underscores or camel case (e.g. main_out_L or mainOutL).  

The target/destinations for send/send~/receive/receive~ are case-sensitive.  When I make a receive, I copy and paste it to make the send so I don't accidentally mess up the case.  Best practice is to pick a naming convention and stick with it, because this kind of error can be a royal pain to debug.

Other useful thing: you can use an argument at the front of receive names, such as #1_channel, #2_channel.  (has to be at the front)  This lets you specify the names of the receives using arguments to your bpatcher which will make the whole thing more flexible.

Also, if you want to make local sends and receives, use #0 in front of the name of the receive. In this case it you've got a "s tempo" in each bpatcher, and that's probably causing confusion, since it means that all of the loops are getting reset 4 times.  If you use "s #0_tempo" it will create a send that's unique to that bpatcher.  The #0 creates a unique 4 digit id on load that is specific to that patcher, so your sends would look something like 1001_tempo, 1002_tempo, 1003_tempo, 1004_tempo.


Patrick: The different instances of that patch are to allow for different buffers~, so I can have different samples playing at once. Though my method is probably not the best, haha. I blame ignorance. I'll load up your patch once I get back from work, thank you.

And the spaces must be it! That makes sense, thank you Peter + Patrick. I had no idea the spaces separate arguments.

To use different buffers, just use the same technique as with send/receive names: instead of the buffer's name, use the 

 placeholder and put the right buffer name as second argument of the bpatchers.

To use different buffers, just use the same technique as with send/receive names: instead of the buffer's name, use the #2 placeholder and put the right buffer name as second argument of the bpatchers.


Problems w/ send~ and receive~