Trouble with patterns

[3n3l]

I can't even get the simplest pattern (based on an old example from the project description on pypi) to produce any sound.
I tried different patterns based on examples from doc.sccode (with and without instrument/frequency/etc. in the pattern), different context, with and without target_node/clock/etc. in pattern.play(), but nothing ever happens.

I'm clearly missing something, but what is it?

from supriya import Server
from supriya.patterns import EventPattern, ParallelPattern, SequencePattern

server = Server().boot()
pattern = ParallelPattern([
    EventPattern(
        frequency=SequencePattern([440, 550]),
    ),
    EventPattern(
        frequency=SequencePattern([1500, 1600, 1700]),
        delta=0.75,
    ),
])
player = pattern.play(context=server)

[josiah-wolf-oberholtzer]

Short answer: you need to send the pattern's SynthDef to the server before you can create Synths that use it. In this case, it's the default SynthDef supriya.default. This is basically the same behavior you'd also get with sclang: gotta send the SynthDef before you can use it.

server.add_synthdefs(supriya.default)
server.sync()  # wait for the server to load the SynthDef completely

Longer answer: if you turn on logging output you can see the failure messages coming back from the server. This is gonna be very verbose - in the current version of Supriya the failure messages are output at the same logging level as just about everything else (DEBUG).

After you run server = Server().boot(), run the following:

import logging
logging.basicConfig() # a basic logging setup in a can, ensure log messages go to stdout
logging.getLogger("supriya.osc.in").setLevel(logging.DEBUG) # we'll dial up just logging of messages replies from the server

... and then run your pattern block. You'll see /fail messages mixed in with the standard /status.reply healthchecks:

DEBUG:supriya.osc.in:[127.0.0.1:57110] OscMessage('/fail', '/s_new', 'SynthDef not found')
DEBUG:supriya.osc.in:[127.0.0.1:57110] OscMessage('/fail', '/s_new', 'SynthDef not found')
DEBUG:supriya.osc.in:[127.0.0.1:57110] OscMessage('/status.reply', 1, 0, 0, 2, 32, 0.027917437255382538, 0.20268774032592773, 44100.0, 44100.19647253151)
DEBUG:supriya.osc.in:[127.0.0.1:57110] OscMessage('/fail', '/s_new', 'SynthDef not found')
DEBUG:supriya.osc.in:[127.0.0.1:57110] OscMessage('/fail', '/s_new', 'SynthDef not found')
DEBUG:supriya.osc.in:[127.0.0.1:57110] OscMessage('/fail', '/n_set', 'Node 1000 not found')
DEBUG:supriya.osc.in:[127.0.0.1:57110] OscMessage('/fail', '/n_set', 'Node 1001 not found')
DEBUG:supriya.osc.in:[127.0.0.1:57110] OscMessage('/status.reply', 1, 0, 0, 2, 32, 0.09106212109327316, 0.7139376401901245, 44100.0, 44100.2238074192)

[josiah-wolf-oberholtzer]

Hi @macduff111, thanks for the compliments 😄. I realize there's not a lot of docs, but I unfortunately don't have a lot of time. C'est la vie.

To choose a Synthdef for an EventPattern, just add a synthdef=<reference-to-your-synthdef-here> to the EventPattern definition.

pattern = ParallelPattern([
    EventPattern(
        frequency=SequencePattern([440, 550]),
        synthdef=my_synthdef,
    ),
    EventPattern(
        frequency=SequencePattern([1500, 1600, 1700]),
        delta=0.75,
        synthdef=my_other_synthdef,
    ),
])

Without that key, the event pattern will just use the "default" SynthDef. This is sort of equivalent to the \instrument key to Pbinds in sclang.

[josiah-wolf-oberholtzer]

Probably makes more sense to open a new discussion, since this is a slightly different topic, but whatever.

[macduff111]

That's great thanks. I got close - I tried with instrument= in the pattern.

Yes, sorry, should have started a new question.

[josiah-wolf-oberholtzer]

@macduff111 Also you can often dig through the test suite to find examples. That doesn't quite hold for the pattern stuff though, since those tests are heavily parametric and kinda hard to read.

[macduff111]

Yes I tried that too but like you say the Pattern tests are pretty cryptic !

[josiah-wolf-oberholtzer]

And mea culpa re: why this category of problem is non-obvious. I need to find a clean way to surface these failures that still plays nice with the logging regime.

[josiah-wolf-oberholtzer]

I opened a PR to print warnings when those /fail messages are received: #348