Why am I getting an error when putting osc/ objects in subpatch

I’m trying to port over some old axoloti patches and I noticed that I was getting this error—>“error: ‘osc’ was not declared in this scope”

I found that I keep getting this error whenever I have an osc object within a subpatch.

Is this a bug?

I can confirm, just tried Braids plucked Osc worked fine in mono mode, but as soon as I placed it in a poly patch compiler threw up the same osc not declared in scope error.

Looks like a bug to me, will you report it on github or shall I?

Generate code complete
Compiling patch.
/Users/reubenfinger/Library/Akso/build/xpatch.cpp:360:1: error: ‘braids_digital_deriv’ does not name a type
braids_digital_deriv::Plucked osc;
^~~~~~~~~~~~~~~~~~~~
/Users/reubenfinger/Library/Akso/build/xpatch.cpp: In member function ‘void rootc::instancepatcher__1::voice::instanceplucked__1::Init(rootc::instancepatcher__1::voice*)’:
/Users/reubenfinger/Library/Akso/build/xpatch.cpp:363:1: error: ‘osc’ was not declared in this scope
osc.Init();
^~~
/Users/reubenfinger/Library/Akso/build/xpatch.cpp:363:1: note: suggested alternative: ‘cosl’
osc.Init();
^~~
cosl
/Users/reubenfinger/Library/Akso/build/xpatch.cpp: In member function ‘void rootc::instancepatcher__1::voice::instanceplucked__1::dsp(rootc::instancepatcher__1::voice*, int32_t, int32_t, int32_t, bool, int32_t (&)[16], int, int, int)’:
/Users/reubenfinger/Library/Akso/build/xpatch.cpp:378:1: error: ‘osc’ was not declared in this scope
osc.set_parameters(__USAT((inlet_timbre+param_timbre)>>12,15),__USAT((inlet_color+param_color)>>12,15));
^~~
/Users/reubenfinger/Library/Akso/build/xpatch.cpp:378:1: note: suggested alternative: ‘cosl’
osc.set_parameters(__USAT((inlet_timbre+param_timbre)>>12,15),__USAT((inlet_color+param_color)>>12,15));
^~~
cosl
make: *** [/Users/reubenfinger/Library/Akso/build/xpatch.o] Error 1
shell task failed, exit value: 2
Compiling patch failed.
axoloti.shell.ExecutionFailedException
axoloti.shell.ExecutionFailedException
at axoloti.shell.ShellTask.run(ShellTask.java:120)
at axoloti.shell.ShellTask.lambda$getJob$0(ShellTask.java:37)
at axoloti.shell.CompilePatch.lambda$run$0(CompilePatch.java:67)
at java.base/java.lang.Thread.run(Thread.java:834)

axoloti.shell.ExecutionFailedException
axoloti.shell.ExecutionFailedException
at axoloti.shell.CompilePatch.run(CompilePatch.java:75)
at axoloti.live.patch.PatchViewLive.lambda$goLive$7(PatchViewLive.java:275)
at axoloti.job.JobProcessor.lambda$exec$0(JobProcessor.java:21)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)

Yikes. This is the first time I’ve noticed gcc’s fix-it hints. My initial reaction is that it’s a crazy idea.

About to run.

If you can report it would be much appreciated. if not I can tomorrow @reubenfinger

Not surprised that the Braids stuff specifically is having trouble in subpatches. Definitely log an issue. I suspect that the Braids stuff may actually be partially to blame for compilation performance as well; there’s some optimization that needs to be done there as far as how these larger external libraries are included.

If it seems like particular objects are having trouble in subpatches but not others, log those specifically. It sounds like there may be a common underlying cause here.

I’m finally getting to a point where some of the logistics stuff is finally dying down a bit, and I should be able to carve out some time to cut a patch release.

Aside:

One of the really simple things I’m thinking about doing: compilation caching. Possibly even pre-compiling all examples and community patches. If a patch hasn’t changed and you’ve previously compiled it, we should just load the cached binary directly. Ultimately we should never actually compile an object unless its definition has changed. The basic problem is that we rely way too much on actual text substitution and manipulation to construct the patch source file to be compiled (xpatch.cpp). It should be possible to compile just an object and then link it into a patch binary but purely on the host machine, not necessarily on the target device like in Axoloti 2.0’s approach.

Glad to hear you are finally getting a chance to catch your breath.

I’m unsure what OSC aSoundingBell was having issues with. However I spent a small amount of time this morning creating a similiar poly subpatch with a Supersaw OSC and did not get the error, so I have raised an issue on github based on the Braids OSC’s

2 Likes