The csound output does not trigger the onTrigger pattern

[gogins]

The following Strudel patch can be pasted into the REPL and demonstrates the issue:

csound_trigger.txt

If the csound output is enabled by uncommenting line 51, then the Csound output plays, but the onTrigger pattern is not triggered, and the generated notes do not climb in pitch. If the csound output is disabled by commenting out line 51, then the piano output plays, the onTrigger pattern is triggered, and the generated notes do climb in pitch.

[felixroos]

yes, that is to be expected, because Pattern.csound will override the .onTrigger on the hap context. having multiple triggers is not implemented yet.. but it could be done easily, by just collecting triggers in an array.

[gogins]

What about using a non-dominant trigger for the Csound output, as in the stateful pattern example?

[felixroos]

What about using a non-dominant trigger for the Csound output, as in the stateful pattern example?

it still wouldn't work to call onTrigger 2 times, as the second call will always override the "onTrigger" property of Hap.context. it might be clearer by looking at the source

edit: I did not realize that multiple triggers are possible, but only when dominant is false, so it would technically work, but the problem would then be that the defaultOutput would also trigger, which is not what we want

[felixroos]

hm thinking about this again, it might also work by checking the dominantTrigger of the existing hap, as an existing onTrigger will already be called https://github.com/tidalcycles/strudel/blob/main/packages/core/pattern.mjs#L787

[felixroos]

this is the other relevant place: https://github.com/tidalcycles/strudel/blob/main/packages/core/repl.mjs#L82
the csound output (and similar ones) would need to override the defaultOutput (which is what dominantTrigger does) but still call pre-existing triggers.. so maybe it will already be fine if

https://github.com/tidalcycles/strudel/blob/main/packages/core/pattern.mjs#L786

is changed to

 if (hap.context.onTrigger) {

the question would be if there is a use case where you would want to ignore an existing onTrigger callback..

[gogins]

I have implemented your suggestion in my local Strudel and it seems to work fine without messing up existing pieces in the REPL "Shuffle."

[felixroos]

should now be fixed. there was another weird behavior when you'd add a non-dominant trigger after a dominant one, then the default output would be activated again.

[gogins]

This is no longer working as I expected. The attached patch can be run to demonstrate the issue.

• For the default output, the notes appear to be correctly computed but the piano roll jumps up and down during performance.
• For the csound output, the notes are not correctly computed; the value of state is computed, but is not added to the notes going to Csound.

csound_trigger.txt

[felixroos]

the changed merged in #660 is not yet deployed so nothing should've changed, which means .csound will still overwrite your trigger. without csound, the piano roll jumping around is to be expected because you're using global state that is not integrated with the used patterns

[felixroos]

now it's deployed, so now the onTrigger will always get called (with or without csound being used).

[gogins]

I made to sure to completely clear my browser cache and application data. The deployed REPL now does play notes with the added state, both for the default output and for the Csound output. Thanks for that!

However, the pianoroll display is still jumping up and down in both cases.

[felixroos]

However, the pianoroll display is still jumping up and down in both cases.

yes, that is because you're using an external state variable inside the withHap callback, turning it into a non-pure function, breaking the whole pure functional programming paradigm. As said earlier, it's not a solution, it's a workaround.
The pianoroll jumping around is only one symptom, you will also not be able to use pattern methods as expected.
I'd recommend trying to solve your problem without state (if possible).

in tidal, this problem is already solved like this: https://tidalcycles.org/docs/reference/state_values/

[gogins]

Thanks for your helpful comments. Yes, I have been aware of this conflict between functional programming and imperative programming. Background: I have created software (CsoundAC, written in C++ and compiled to WebAssembly) that does various neo-Riemannian transformations of chords and scales. What I was hoping to do is compute these transformations on cycle onsets, and apply the resulting values in all queries within such cycles. I was originally trying to do this in a purely functional way, but it seemed to involve a lot of unnecessary, repetitive computation. Also, I couldn't see how to unambiguously identify the cycle onsets in the withHap callback, so I tried using triggers. Perhaps I didn't understand what I was seeing.

…

----------------------------------------------------- Michael Gogins Irreducible Productions http://michaelgogins.tumblr.com Michael dot Gogins at gmail dot com

On Tue, Aug 15, 2023 at 2:45 AM Felix Roos ***@***.***> wrote: However, the pianoroll display is still jumping up and down in both cases. yes, that is because you're using an external state variable inside the withHap callback, turning it into a non-pure function, breaking the whole pure functional programming paradigm. As said earlier, it's not a solution, it's a workaround. The pianoroll jumping around is only one symptom, you will also not be able to use pattern methods as expected. I'd recommend trying to solve your problem without state (if possible). in tidal, this problem is already solved like this: https://tidalcycles.org/docs/reference/state_values/ — Reply to this email directly, view it on GitHub <#658 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABQIGJK7C64JOVRFOQLRYXDXVMLJNANCNFSM6AAAAAA3KIZCLQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>