seadnamc

I have just started using bpatchers and i am having some problems. I have 1 patch with a step sequencer and all my interface elements. I have another patch with a couple of bpatchers, using tabs and different offsets to navigate around my interface. When i click on the button that should start my step sequencer nothing happens. I'm not sure if i grasp the concept of bpatchers correctly. I thought that the bpatcher is a 'window' into another patch but it seems that when i click the button to start the step sequencer, the patch that actually contains the step sequencer does'nt 'know' that it has been pressed. Should i be putting the button that starts the sequencer in the patch that contains the bpatcher and send a message in to an inlet of the bpatcher?

bpatcher-functionality-problems

hard to tell without seeing a patch... but in general it should work the way you are describing it.

I cannot figure out what is wrong. I created a mini step sequencer as a test and that works as it should in both the subpatch and the bpatcher. Can anyone tell me how to save my patch as a txt file so i can post it up here?

"Copy Compressed" puts a forum-friendly version of your patch on the clipboard. You'll need to to this for the bpatchers as well as the parent patcher.

I _think_ I might know the source of your confusion: Bpatchers are not windows into another currently open patch - they are more akin to subpatchers in that the patching in the bpatcher is actually running. If you are expecting your step sequencer patch (loaded elsewhere) to be 'controlled' by a bpatcher that has the same patch loaded, that won't work. The bpatcher IS the patch. If you want to get any information out of the bpatcher, you have to use outlets (and inlets for info into it), or sends/receives.

It references the same data, but in terms of processing, bpatchers are their own instance of a patch.

I _think_ I might know the source of your confusion:  Bpatchers are not windows into another currently open patch - they are more akin to subpatchers in that the patching in the bpatcher is actually running.  If you are expecting your step sequencer patch (loaded elsewhere) to be 'controlled' by a bpatcher that has the same patch loaded, that won't work. The bpatcher IS the patch.  If you want to get any information out of the bpatcher, you have to use outlets (and inlets for info into it), or sends/receives. 

It references the same data, but in terms of processing, bpatchers are their own instance of a patch.


I think i understand a bit more about the bpatcher now. I realise that you are not actually looking into our other patch, rather it is an instance of your patch. Taking this on board, i figured out my problem. But now i have another one. in the sub patch i have a step sequencer triggering pitches from a multislider. I can turn the steps on and off but i cannot change the pitches. I have an out-let in the bpatcher taking out the midi notes that are coming from the multi slider, and then connected to a makenote and noteout objects but they are not registering in parent patch. Everything works fine in the subpatch on its own. How do i do copy compressed to post my patches?

Here's the parent patch with the bPatchers:

Why do you have two copies of your bpatcher? If it's just so that you can have the trigger section at the bottom, I would break that section out into a second bpatcher. At any rate with the way you are using send/return you end up sending duplicate messages in a lot of cases. You could give each bpatcher an argument and make different message destinations.

If it were me, I'd break this out even further than that, Chris - There's 4 copies of a section with 6 multisliders apiece - which to me could be 6 bpatchers nested in another 4 bpatchers. Then there's the jillion other multisliders, and the 4 copies of the trigger section, which could also all be bpatchers nested in other bpatchers.

It takes slightly more thought (and more dealing with #0 arguments) to set it up, but then it becomes about a thousand times easier to add another sequencer section, or more multisliders, or to change your color scheme or whatever. If you've got an interface with a lot of repeated elements, there's no need to manually make each and every one - just one copy of the interface with multiple bpatcher instances tends to work much better, in my experience. Then if you want to change something, you only have to do it once, and watch your changes propagate to all the instances you've got of it.

It takes slightly more thought (and more dealing with #0 arguments) to set it up, but then it becomes about a thousand times easier to add another sequencer section, or more multisliders, or to change your color scheme or whatever.  If you've got an interface with a lot of repeated elements, there's no need to manually make each and every one - just one copy of the interface with multiple bpatcher instances tends to work much better, in my experience. Then if you want to change something, you only have to do it once, and watch your changes propagate to all the instances you've got of it.


Thanks for the suggestions guys but i am still having trouble with my patch. You both seem to be talking about interface issues but my main problem right now is the functionality of what i have right now. It seems like the step sequencer should be functioning in the same way as it does when i run it in the sub patch. To start adding more bPatchers seems like i would be getting ahead of myself. I think i would really just like to figure this out first and then i could move on to more complex things.

Hang some print objects on some of your send/receives and you'll see what I'm talking about. Because the send/receive namespace is global, by having the same patcher instantiated twice in the two bpatchers, you are doubling up on all sends and receives. For example, pitch gets sent from both bpatcher instances. Each bpatcher is a unique instance of the patcher.

Hang some print objects on some of your send/receives and you'll see what I'm talking about. Because the send/receive namespace is global, by having the same patcher instantiated twice in the two bpatchers, you are doubling up on all sends and receives.  For example, pitch gets sent from both bpatcher instances. Each bpatcher is a unique instance of the patcher.


I think i understand but the reason i am using two bpatchers is because their offsets are being controlled differently. The bottom one is being offset horizontally the other is being offset horizontally and vertically. I am new to using bPatchers and i am still trying to understand the way that they work. Should i put the step sequencer in one subpatch and the multisliders in the another subpatch and communicate between them via unique bPatchers with inlets or outlets. I do not understand the scripting name and how to set unique ids. Maybe someone could clarify this for me.

I think i understand but the reason i am using two bpatchers is because their offsets are being controlled differently. The bottom one is being offset horizontally the other is being offset horizontally and vertically. I am new to using bPatchers and i am still trying to understand the way that they work. Should i put the step sequencer in one subpatch and the multisliders in the another subpatch and communicate between them via unique bPatchers with inlets or outlets. I do not understand the scripting name and how to set unique ids. Maybe someone could clarify this for me.
Thanks.


What I suggested a few messages back is braking your "Interface1copy.maxpat" patcher into two patches, the trig sequencer and the slider part. If you did this, you would eliminate the redundancy and associated double-messages, and your patch would take less memory.

MuShoo pointed out other benefits from dividing it further, which I agree with, but that is more of an architectural refinement, not a get-this-sucker-working sort of thing.

Ok, I will try this. It should be a good learning experience for me to say the least. Thanks guys for your suggestions.

Bpatcher Functionality Problems