Maybe, someone here knows how to answer these 2 questions concerning PmonoArtic :
If there a way to switch between different synthDefs with PmonoArtic during the rearticulation (since a new synth is triggered) ?
Is there a way to crossfade between these 2 PmonoArtic with different legato in a Pdef without errors ?
Pdef(\one).fadeTime_(2);
Pdef(\one, PmonoArtic(\default, \dur, 0.2, \freq, Pwhite(1,8) * 100 , \legato, 1)).play
Pdef(\one, PmonoArtic(\default, \dur, 0.2, \freq, Pwhite(1,8) * 100, \legato, 0.2 )).play // the crossfade is ok
Pdef(\one, PmonoArtic(\default, \dur, 0.2, \freq, Pwhite(1,8) * 100 , \legato, 1)).play // the synth is released, resulting in a lot of FAILURE IN SERVER /n_set Node 4831 not foundâŚ
Regarding your first question: you can change/set the synthName member variable asynchronously. E.g.
p = PmonoArtic(\default, \dur, 5, \amp, 0.8, \freq, Pseq([555, 666], inf), \legato, 0.6)
e = p.play
SynthDef(\sine, { |out=0, amp=1, gate=1, freq=555| Out.ar(out, amp!2 * EnvGen.ar(Env.asr(), gate, doneAction: 2) * SinOsc.ar(freq) )}).add;
p.synthName = \sine // this takes effect on the next note with legato < 1
e.stop
If you want this to happen from the event stream, youâd have to insert some kind of pseudo event that just does this (e.g. with \amp set to zero) and some Plazy that does synthName change as a side effect, e.g.
But is there a way a to integrate PmonoArtic within Pdef (for crossfade) and play with the legato (< 1 or > 1) without generating errors in the post window, as shown in my first post ?
Although Iâve stopped using PmonoArtic for more complicated reasons, this issue is still quite befuddling to me. Pdef with crossfade (non-nil fadeTime) does this:
But amusingly, the bug doesnât seem to be in that code:
x = PmonoArtic(\default, \dur, 0.2, \freq, Pwhite(9,16) * 100, \legato, 0.2, \amp, 0.05);
y = PmonoArtic(\default, \dur, 0.2, \freq, Pwhite(1,5) * 100 , \legato, 1, \amp, 0.2);
p = Ppar([x, y]).play // ok
p = Ppar([PfadeOut(x, 5), y]).play // ok
p = Ppar([x, PfadeIn(y, 5)]).play // ok too
p = Ppar([PfadeOut(x, 5), PfadeIn(y, 5)]).play // ok in combo
// even this works!
p = Ppar([EmbedOnce(PfadeOut(x, 5), EventStreamCleanup.new), PfadeIn(y, 5)]).play
At least that gives a workaround to using Pdefâs own crossfade.
Iâm not sure what EmbedOnce is for, by the way. It actually seems to prevent some such failures, at a least on stop
p = Ppar([PfadeOut(y, 5), PfadeIn(x, 5)]).play // ok
p.stop // prints some failure if called after y fully fades
p = Ppar([EmbedOnce(PfadeOut(y, 5), EventStreamCleanup.new), PfadeIn(x, 5)]).play
p.stop // seems to prevent that failure
Also, an attempt at a workaround âa Pdef layer belowâ didnât quite work as expected
v = Pbind(\dur, 0.2, \freq, Pwhite(9,16) * 100, \legato, 0.2, \amp, 0.05)
w = Pbind(\dur, 0.2, \freq, Pwhite(2,4) * 100 , \legato, 1, \amp, 0.2)
Pdef(\two, PmonoArtic(\default) <> Pdef(\data))
Pdef(\data).fadeTime_(5)
Pdef(\data, v)
Pdef(\two).play
Pdef(\data, w) // v fadeout but not w fade in...
I suspect the actual problem is that EventPatternProxy reuses its cleanup object when you change its source (does not re-init the cleanup), so it might be contaminated with stuff from previously set sources. Iâve (finally) managed to repro it by doing what Pdef is doing internally on a source swap:
I doesnât bomb immediately on source swap though, but after the fading in Ppar finishes.
The cleanup system in SC quite buggy, so the actual problem may be elsewhere. For now, itâs best to avoid patterns that use cleanup, even internally (like Pmono series).
Actually what happens is that cleanup for the stuff being cross-faded in gets called as soon as the cross-fade is done. The next code doesnât stop on cross fade, but cleanup gets called (which in this case is harmless, unlike for Pmono or PmonoArtic with legato >= 1)
Somewhat simpler code to show where the problem is, namely the cleanup gets called prematurely:
Pdef(\two).fadeTime_(2);
Pdef(\two, PmonoArtic(\default, \dur, 0.2, \freq, Pwhite(2,4) * 100 , \legato, 1)).play
// no stops with the next, but the cleanup gets called!
Pdef(\two, Pfset({}, Pbind(\dur, 0.2, \freq, 440), { "bye".postln })).play
Thank you so much for reporting this issue on Github and trying to solve it.
Iâve downloaded the latest build of SC with the pull request that should solve this issue, but I still have problems with a lot of FAILURE IN SERVER /n_set Node XXXX not foundâŚ
Unfortunately, I donât have the knowledge why there is still this error ?
âthe latest build of SCâ meaning a devel build? Open Pdef.sc and see if you find the fadeOutCleanup string in it.
N.B. You can just patch the Pdef.sc file in any build. I did that with my âproduction 3.10.4â and I can tell you the example youâve posted at the top of this thread works fine now.
Iâve tested with the latest devel build and I can find within Pdef.sc âfadeOutCleanupâ,
but I still have errors. donât know what I am doing wrong⌠?
Ok, are you sure youâre actually running the build youâve downloaded and itâs not reading the class files from somewhere else? Because itâs in the âworks for meâ varietyâŚ
ERROR: Class not defined.
in interpreted text
line 1 char 21:
TestEventPatternProxy.new.test_EventPatternProxy_xfade_cleanupNotPremature
-----------------------------------
â nil
However, I am sure that I run the latest devel build, since when I open Pdef.sc, I can see âfadeOutCleanupâ. I also tried without my extensions in case.
I dropped your code in a .sc extension, recompiled, saw the overwrites.
But I still have the error. very strange. donât know why we have different results.
Ok, you should probably file a new ticket on github and/or leave a comment for the old one to be reopened. But youâll have to provide more details than âit doesnât work for meâ.
Iâd be curious to hear what @jamshark70 thinks happens here. Because he also tested some earlier versions of the patch (in fact he came up with the solution). And I suspect Julian (telephon on github) tested it too; he was the initial code reviewer for the PR.
Do try to get the testuite running on your box. You need edit sclang_conf.yaml either manually or from the scide (if thatâs what yourâre using as SC front-end); with the latter itâs in the Edit > Preferences > Interpreter > Include and add a full path to the test suite⌠which would be the testsuite subdir of wherever youâve downloaded the source for the SC develop tree, i.e. something like
/<your path to develop SC tree>/testsuite
There should be a TestEventPatternProxy.sc in testsuite/classlibrary; this was committed recently to develop.
(You should see your installed quarks listed in the yaml file and/or scide preference too.)
You could also run the code below, which is âmanualâ version of the unit test, with more debugging printed:
(
{
var test_EventPatternProxy_xfade_cleanup_not_premature = {
var assert = { |what, which, important = true|
var msg = if(what) { "PASS" } { "FAIL" };
(msg ++ ":" + which).postln;
};
var stream2_cleanup_called = false, p = EventPatternProxy.new.fadeTime_(2), r;
p.source = Pbind(\dur, 1.1, \degree, 3, \amp, 0.1);
r = p.asStream;
// pulling one event is necessary to prime the old stream
assert.(r.next(())[\degree] == 3,
"EventPatternProxy xfade 1st source 1st pull shold be executed transparently.");
p.source = Pfset({},
Pbind(\dur, 1.3, \freq, 440, \amp, 0.4),
{ stream2_cleanup_called = true });
// Pull enough events to exhaust the xfade.
// There should NOT be a cleanup of the 2nd stream executed,
// since it's an infinite stream (of the same event).
// Three more events should be enough to pull here to
// end the cross-fade, but "just in case" we pull 6.
6 do: { r.next(()).postln };
assert.(stream2_cleanup_called.not,
"EventPatternProxy xfade 2nd source cleanup should be not called prematurely.");
// todo: might also wanna check that the cleanup was sent downstream (addToCleanup seen)
};
test_EventPatternProxy_xfade_cleanup_not_premature.();
}.value;
)
PASS: a TestEventPatternProxy: new - EventPatternProxy xfade 1st source 1st pull shold be executed transparently.
Is:
3
Should be:
3
PASS: a TestEventPatternProxy: new - EventPatternProxy xfade 2nd source cleanup should be not called prematurely.
â a TestEventPatternProxy
But, still, when I evaluate the last line of the below code with the latest develop build, I still have errors with FAILURE IN SERVER /n_set Node :
Iâll try a Linux build later today or tomorrow. In the meantime, manually applying just that patch to 3.11.0 on a Windows 10 installation âfixed itâ, i.e. your last example bombs without the patch but works fine after reloading the class-lib with the patch (meaning the one from above overriding that constrainStream.) Likewise for the Canonical-provided SC 3.10.0 on Lubuntu 20. I donât have a Mac, so I cannot try it there.
Can you try just patching a 3.11.0? Does only develop fail for you?
I did a linux build and I can confirm the bugfix doesnât fully fix develop, event though it does fix 3.11.0!! Iâll try to have the bug report reopened.
the last line is still bugged on develop. It looks like it will take more investigation to find out why.
If yourâre willing to beta-test new cleanup system (which fixes several more bugs) it seems it solves this one too in develop (and yeah, Iâve checked it wasnât actually enabled in other non-develop testsâitâs easy to see because the new system doesnât pass bare functions in addToCleanup).