Hello, I have a technical problem I hope someone can help with. I'm working on a simple sequence that switches between two guitar chords, A and D. Each chord strum is recorded as 4 separate samples, and I have set my patch up so that a random sample is played for each strum, to add a bit of interest and variation to the loop.

Changing chords between A and D is automated in my actual patch, but here I have simplified it so that I click the message boxes banually to try to debug my problem.

The problem is that when the message box is clicked or banged, it doesn't only send the list to be split and opened and read below, but it also plays all the files in the message immediately on click/bang.

My question is, is there a way to silently trigger the array of files in the message box so that they get sent to the list to be split, etc?

@soundproofskin Connect the [list split]s to the right inlet of the [symbol] and the [sel 0 1 2 3] to the left. Also, [unpack s s s s] will make things a bit neater than the [list split]s and as a general rule of thumb [pack] and [unpack] are more efficient than [list] objects so are a better way to go when you are dealing with short lists of a known number of elements.

The [open $1, 1( are two successive messages: [open $1( and [1(, where the later is the same as [start(

@oid Beautiful, thanks. I don't know why the sound doesn't trigger when the message is banged with using symbols this way but it works so I'll note that for next time. Thanks for the other tips too, it looks much tidier.

@lacuna I think I understand that, but I don't get how it was linked to a bang on the message array playing the files.

@soundproofskin said:

I don't know why the sound doesn't trigger when the message is banged with using symbol this way

Because you skipped over learning the basics, objects have hot and cold inlets, hot intlets produce output, cold inlets affect the object's state, vast majority of objects only have the left inlet as a hot inlet with the other inlets configuring the object but producing no output. Might want to dig into the manual, it will save you a good amount of time down the road. @lacuna's answer is actually the correct answer, I did not look close enough at your patch, as it stands you are reloading the sample every time you play it, only need to load it when the sample being played changes.

@oid said:

Because you skipped over learning the basics, objects have hot and cold inlets..,

This idiom, of sending values forward to be stored passively, is critical to successful patching but also seems to be difficult to grasp. Taking myself as example, while I wasn't a CS student, I think I know my way around an algorithm or two, but when I started teaching with Pd, it took me over a year to understand this well.

It's a crucial part of "the basics," but it does take some effort to really get it.

I've thought for a while that Collatz series are a good example of the awkwardness of patching for if-then-else, because a value is used separately in the "then" and "else" branches.

A simple SuperCollider Collatz series function is pretty clear and concise.

(
f = { |x|
    while { x != 1 } {
        if(x.even) {
            x = x div: 2
        } {
            x = x * 3 + 1
        };
        x.postln;
    }
};
)

The thing that is difficult for patching to handle is that this variable 'x' is referenced in three places, and two of those are conditional -- if 'x' is a patching object, you can't just connect a single [f] box to all of its downstream paths because, in each iteration, one or the other needs to be suppressed.

One way is to set [spigot]s opposite Booleans, and push the value through both of them -- always try to go down both paths, but one of them is blocked.

(
f = { |x|
    var cond;
    while { x != 1 } {
        cond = x.odd;
        if(cond.not) {
            x = x div: 2
        };
        if(cond) {  // two ifs? hmm...
            x = x * 3 + 1
        };
        x.postln;
    }
};
)

Another way is to push the value into separate [f] variables, but bang only one of them.

(
f = { |x|
    var trueX, falseX;
    while { x != 1 } {
        trueX = x;    // lol
        falseX = x;
        if(x.even) {
            x = trueX div: 2
        } {
            x = falseX * 3 + 1
        };
        x.postln;
    }
};
)

And a third way is to mimic [cyclone/gate] by binding the value and the condition together, and using [route] to dispatch.

(
f = { |x|
    var bind;
    while { x != 1 } {
        bind = [x, x.even];
        // 'pop' pops from the end,
        // similar to [route] popping from the start
        if(bind.pop) {
            x = bind[0] div: 2
        } {
            x = bind[0] * 3 + 1
        };
        x.postln;
    }
};
)

All three of these IMO read a bit awkwardly in code (though, using [cyclone/gate] would simplify the third one)... but they're structural necessities in the Max/Pd messaging layer. These are "basics" but not exactly intuitive -- a pedagogical problem.

collatz.pd

hjh

I'm down with an illness at the moment, but just wanted to say thanks for the replies, I'll go through them properly when I am better.