Bit skeptical of this! Why does Nyquist theorem care whether your sinewaves are harmonics or not? (maybe I’m misunderstanding what you mean by 'account for difference tones)

1 Like

aho! sorry you’re right. i have been up too late and confused a difference of signals with a difference of frequencies ( multiplication of signals.) then i got paranoid that i might lead someone astray with weird claims. but my young [then] self was smarter (? no) and less tired (? yes) than my old [now] self.

2 Likes

ah good, started getting really worried there I just didn’t know how to apply Nyquist (certainly wouldn’t claim to understand it)

anyone know where to put custom ugens on norns 2.0? It was defeating me late last night

yeah that’s a bit of a hole in the current proposal(s). the compiled .so/.scx can live in ~/dust or wherever. whence the code?

for the moment you can put the ugens in
/home/we/.local/share/SuperCollider/Extensions/ and it should work

but this directory got cleared out (deleted) on the last update so I’m not sure it’s the “official” location. Just keep in mind that you may need to re-install those ugens again after the next update.

1 Like

Can anyone walk me through getting Crone Engine development running locally on my Mac? I have the Norns classes in my path, but instantiating one (TestSine) to test it locally throws a bunch of errors. seems to need a bunch of scaffolding around it (no context.xg found, etc)

The feedback loop with sending an engine to the Norns and then restarting is a little slow for someone like me, who is just getting started and constantly making basic syntactical mistakes. I made a pannable version of @tehn’s PolyPerc that way and it was slow going.

2 Likes
n = NetAddr.localAddr;

n.sendMsg('/engine/load/name', 'TestSine');

// equivalently:
// Crone.setEngine('Engine_TestSine')

n.sendMsg('/command/hz', 330);
n.sendMsg('/command/amp', 0.5);

you may also want to comment out these lines about jack connections on macos

3 Likes

Excellent, thanks for this! Ultimately it would be great to roll this process (plus setting up the class paths) into an “engine development study” in the docs.

It takes a little mental gymnastics as someone new to SuperCollider, as most of the tutorials and documentation is around working in the interpreter - select and execute - vs interacting with a compiled class.

2 Likes

Would you mind sharing your code? I have the same need.

I threw together a quick gist as a guide. @zebra’s advice was perfect, I just packaged it up.

(The jack errors must fail silently so I didn’t bother commenting them out.)

8 Likes

thanks - left some feedback on the gist

From tinkering today I’ll also add this: it seems easier when developing a new norns engine to mess around directly with SynthDefs, and then wrap it in an engine class once you’ve got something.

Updated the gist. I had no idea that file was generated automatically!

yeah, it won’t matter unless you’re actually running jack on macos - which is unusual but not unheard of. it’s required on linux.

Check out CroneGenEngine, which builds engines from SynthDefs. :slight_smile:

2 Likes

engine development study would be amazing. i hope to make this one day, but unfortunately i’m not terribly sc-smart.

i will, however, make a softcut study as soon as i get a minute after 2.0 is out.

1 Like

Revisiting - Engines that rely on Ugens.

Previously an engine which used a Ugen would require the Ugen and associated code be placed at /home/we/.local/share/SuperCollider/Extensions and then the Engine file itself in the supercollider compile path.

Currently If I drop the Ugens in the dust/code folder structure it does not appear to work.

So questions:

  • is /home/we/.local/share/SuperCollider/Extensions still the best place for ugens?
  • will this directory be wiped in future updates? (or is that just a reset in the 2.0 updater)

And then… What’s the best approach to documenting this process for users to install Ugens required for an Engine?

that /Extensions is just the default place for user stuff in the SC compile path. we used it before we started adding stuff to the path instead. so…

i’m suprised, but haven’t tried it recently. do you get any errors?

(testing with the ugens in a folder at ~/dust/ or ~/dust/code/subfolder)

Everything seems fine with my engine in the SC REPL, until I try to have it do something… then I get

*** ERROR: SynthDef Atari2600 not found
FAILURE IN SERVER /s_new SynthDef not found
*** ERROR: SynthDef Atari2600 not found
FAILURE IN SERVER /s_new SynthDef not found
*** ERROR: SynthDef Atari2600 not found

My test script works fine if the ugens are at /home/we/.local/share/SuperCollider/Extensions

EDIT - oops - I also saw this error:
exception in GraphDef_Recv: UGen 'Atari2600' not installed.

EDIT #2 - i just tried installing the ugens at ~/norns/sc/ugens and this also did not work.

Seems like they have to be installed at the Platform.userExtensionDir location - which is Extenions

ok. so i guess paths installed via LanguageConfig (which the method we use in norns_config.sc) don’t get searched for dylibs when loading ugens. news to me.

installing them in .local/share/... should be fine but of course it creates a more challenging dependency if you want to share scripts.

this might be another argument in favor of just symlinking from .local/share... to ~/dust/code instead of using LanguageConfig.

FWIW, anything in sc3-plugins should already be installed on norns.