buzz forums

When my new build of PeerScale (download) is targeting the newest build of PeerChord (download), if you adjust the PeerScale's 'Peer me!' parameter the PeerChord correctly triggers notes on its target machine. But if you add a pattern for PeerScale and put some values in the 'Peer me!' column, the PeerChord doesn't trigger any notes.

Here's a template with this setup (when you load it, it will play a chord immediately so you'll have to hit stop.)

If you hit play and look at the PeerChord parameter window, you can see the Chord Type param is being changed but it seems that no note is received to go with it. I have the source for PeerChord so I built that too and confirmed that it definitely doesn't receive the 'Root Note' value.

After a bit of head scratching and poking about in the code of both 'Scale and 'Chord, I thought of changing the PeerScale pattern editor from Pattern XP to the old built-in one, which made no difference. Then I changed to the new WPF pattern editor and suddenly the PeerChord worked properly, my breakpoints were hit and notes were played (pattern data for the built-in editors wasn't saved in the template so you'll have to do that yourself, sorry ).

So this looks like a bug in Buzz, or perhaps a really weird bug in one of the peer machines that is somehow circumvented by the new pattern editor. Oskari, please could you look at this? Even if you just confirm whether it's a Buzz bug or not, so I know whether to keep looking for it.

Still trying to figure this out. I've found that the I get the same problem trying to control IX Split from PeerScale. Pattern data only works in the new WPF editor. If PeerScale targets a synth directly, it works fine from any kind of pattern.

So it looks like it's only pt_note parameters on control machines that don't respond properly from old/PXP patterns. All three machines are MIF_CONTROL_MACHINE and MIF_NO_OUTPUT. The PeerScale->PeerMe! param is MPF_STATE and MPF_TICK_ON_EDIT.

For PeerChord, PeerScale does this in Tick()...

For any other machine it just does this...

CPeerCtrl::ControlChange_Immediate() looks like this...

The problem is the same regardless of whether s_immediatebatchmode is true or false.

I've made a simple machine and bmx to demonstrate this problem. The machine has two note params (one global, one track) and a byte param called "Control" and can control another instance of the same machine (set via the dialog). When the Control param is adjusted, the machine sends a global and track note to the target machine. To keep it as simple as possible, I've just used Buzz callbacks to do the control changes, no PeerLib.

The test song is using PatternXP as the pattern editor so make sure the old pattern editor is active.

1. Load the bmx and open the debug console.
2. Manually adjust the "Control" param in the Sender machine param window. The debug console should show that the sender sent some notes and the receiver received them.
3. Hit play. The sender machine control param moves to reflect the values in the pattern but the debug console should show that the receiver doesn't receive the notes.

I've attached the test machine source, dlls and bmx.

I figured it out! You can't call pCB->ControlChangeImmediate() from Tick(). The PeerLib2 docs actually mention that fact so I guess BTD got it from Oskari at some point. I must've read it too at some point but failed to remember it when it was important.

New build of PeerScale soon!