#143

Right - the ones I’m working on are the f0plugins by Fredrik Olofsson

FWIW - i just found a reference to creating a standalone app where they use this:
`// use the internal extensions - repeat this when you move the app!
LanguageConfig.addIncludePath(String.scDir +/+ “InternalExtensions”);

(but I’m clutching at straws here since I don’t really know how all this sc stuff works yet)

Is there something going on here with the already compiled ugens having a hard-coded path to extensions perhaps?

This suggests only one place to put the extensions.

perhaps having ~/dust/ugens symlinked to extensions might be the way to go?

#144

right, well - that advice is consistent with what we’re doing, but evidently doesn’t work if there are custom ugens (dylibs) in the mix. (judging from what you’re seeing; i’ve still yet to try it myself.)

Is there something going on here with the already compiled ugens having a hard-coded path to extensions perhaps?

class files and ugens are used by totally different processes. (sclang and scsynth.) both look for extensions in the - yes - hardcoded (platform-dependent) path returned by Platform.userExtensionDir. (on linux is ~/.local/share/..., on mac is /~Library/Application Support/..., &c)

on reflection, i guess it’s not really surprising that changes effected by LanguageConfig aren’t “seen” by the server. (except that it is kinda surprising. oh well.)

again, an alternative would be to just symlink from the hardcoded location. pretty sure this will work fine for both classes and dylibs. if we did that as part of the norns setup instead of using LanguageConfig then i think custom ugens would work.

i’ll try out a couple things when i’m next on the norns HW, maybe there’s a trick.

1 Like
#145

FWIW - symlinking ~/dust/ugens to extensions throws errors as it tries to compile things twice??? (as it’s in the path twice then)

ERROR: duplicate Class found: 'Atari2600' 
/home/we/.local/share/SuperCollider/Extensions/f0plugins/Atari2600/Atari2600.sc
/home/we/dust/ugens/f0plugins/Atari2600/Atari2600.sc
#146

yes sorry i was unclear - if you do that you should remove norns_config.sc and nuke sclang_conf.yaml. (use LanguageConfig or symlinks, not both)

1 Like
#147

FWIW - I’m mostly worried about this from a “distribution” standpoint so I can properly document how to use these engines I’m working on.

The question/problem is really “what’s the easiest way to do this for the average user downloading this engine + ugens?”

#148

i am wondering about designing my own polysynth crone engine.

with the reversion to SClang and the (small!) performance hit to polyphonic synths vs supernova, i am hoping to sacrifice some sound quality from MollyThePoly to bump the number of available voices up to ~16. short of stress testing on the norns hardware, is there any way to look at existing engines and figure out which parts of them are chugging the hardest? or is it just a matter of looking at the reference file and guessing based on the description how ‘expensive’ it is?

thanks

#149

can’t think of a good way to do this “statically” without just trying it.

you could try developing your thing on the desktop first, watching CPU usage / ugen count &c, compared to Molly or other engines.

understood. unfortunately at this moment there is probably no easier way than to inform users that they must install your ugens to ~/.local/share/... (unless anyone can get it working with custom ugens in some other location.)

w/r/t the symlinking, i’m proposing (/have proposed) that we switch to doing that as part of the standard norns setup. so custom ugens in your project release should just work. this might have other unintended consequences though so we should test it a little more.

1 Like
#150

Is there already a github issue for this?

#151

Have extensions moved . . .? I can’t find /usr/share /.

I am trying to install Atari2600 and have got this far . . .

47
Screenshot 2019-09-19 13.20.47.png1110×738 79.5 KB

. . . but is this the correct place and, if so, the correct way to install such an extension ?

I am getting this message:

exception in GraphDef_Recv: UGen 'Atari2600' not installed.

So I assume the answers to the questions above are no, not correct . . .

So where should extensions, such as Atari2600.sc, be installed ?

#152

Hmmm… is this from my Game-emu work from the f0plugins?

or is this something you’re doing on your own?

In my case the entire f0plugins folder should go in /home/we/.local/share/SuperCollider/Extensions as there’s C code that is required there. The Engine Engine_Atari2600.sc in my case would go in your script folder.

Also - you need to restart supercollider for any engine changes to be recognized (recompiled)

#153

I dragged it from f0plugins, yes. From the /Application Support/ SuperCollider/Extensions/f0plugins folder on my Mac.

Thanks, I’ll drag the complete folder over - and thanks for the plugins too.

#154

Oh wait - your trying this on MacOS?

The f0plugins from my GitHub are complied for linux, they won’t work on Mac. Or your Mac compiled binaries won’t work on Linux (norns)

If you didn’t already, be sure you have the correct compiled binaries for the f0plugins.

#155

I’m trying to use the plugins on my norns but I dragged them from my Mac. You are right of course, I need to download the linux versions from your GitHub. I’ll do that, thanks.

1 Like
#156

hi i hope i am finally at the proper thread to ask about getting supercollider code into Norns
i want to do something basic with gendy

Gendy1.ar(ampdist: 1, durdist: 1, adparam: 1.0, ddparam: 1.0, minfreq: 440, maxfreq: 660, ampscale: 0.5, durscale: 0.5, initCPs: 12, knum, mul: 1.0, add: 0.0)

Do you all think that the Poly_perc example could be modified so i can walk through the process?
i hope this is the right place to ask

#157

you may want to look at this heavily commented passthrough engine

and hey, here’s a gendy thing on my gist too. i forget who this was for but it’s a start of how i like to use gendyN musically. (actually i like to make two of these and x-modulate)

4 Likes
#158

This gist has some advice on getting a Norns engine working on your computer too, which is a useful step before you move it over to the Norns.

And in the Monome We repository, you can find a few example engines like Polysub, where the author went through and made a param for each of the engine parameters.

Unfortunately there isn’t an “end to end” tutorial where you:

  1. Make a SynthDef in SuperCollider
  2. Wrap it in an Engine class
  3. Parameterize it in Lua on the Norns
  4. Add any additional performance-level UI

Which I think would be pretty useful. I’ve gone through the process a couple times now so I’ll try and codify it somewhere.

12 Likes
#159

is there a specific We repository link? or do i pull it off the device?

#160

Thanks for the Gist Help

i followed the directions,
downloaded my “dust” directory form the Norns into my monome/we directory and placed Engine_PolyPercPannable.sc into /MyNornsMachines and made the symbolic links and now i get the nice wakeup drone from crone when SC starts
so that was a good sign
PolyPercPannable gives me the 300hz plonk when i run the code

i tidied up the example @zebra shared

I found that the TestSine example was much easier for my first rodeo and i did not really need to make a class but i do see what’s involved.

I got past the SUPERCOLLIDER FAIL problem but i think my lua script is ineffective to the Engine.

#161

Hey everyone! I’m on day four of having a norns and loving it so far, and I’m already feeling the itch to build a script or few for it. Specifically, in addition to norns’s awesome synths, sequencers, samplers, and loopers, I was hoping for some more effects. Sway and pools and others are great, and softcut’s built-in compressor and reverb are nice too, but I was hoping for something with both a little more range (overdrive, chorus, flanger, bitcrusher, tremolo, EQ, etc.) and customizability (what if you could chain input->overdrive->EQ->tremolo->reverb->output? and change that chain via the encoders and keys?).

So a few questions:

  1. This does not yet exist, yes?
  2. Implementing this would require a new engine, yes? I think using a lot of SC3-provided UGens like JPverb and CompanderD and etc should be sufficient here, but I need a new engine to chain them together I think
  3. It looks like each script can declare an engine with a engine.name = "MyEngine", but it also seems like each script can run exactly one engine? If my goal is custom routing of many small, simple effects together, is the approach I should take: define each effect as its own engine/SC-class/.sc-file, and then make an Engine_MyEngine.sc file that loads these separate engines and routes them appropriately? How does one “import” one .sc file from another .sc file (Engine_MyEngine.sc would import Reverb.sc, Compressor.sc, etc.)? Or do I instead need to put every effect in the same Engine_MyEngine.sc file as… separate synthdefs? This is my first time using SuperCollider, so I’m trying to apply my other programming knowledge here but I’m not quite sure what’s possible / idiomatic SC.

Thanks!

Shortly I’ll be using guides like the one mimetaur posted and zebra’s Engine walkthru gist to develop the Engine(s) on my Mac, then I’ll try my hand at using them in the script I’ve started on the norns itself. The script’s already in a good spot as far as UI is concerned (the provided UI library made this super easy!), so hopefully hooking up its params to the Engine won’t be too rough either :+1:

#162

you could look at @jah’s R engine. this implements a modular environment.

as is good practice, the “kernel” functionality is implemented separately:
{ https://github.com/antonhornquist/r/blob/master/lib/R.sc }

and wrapped in an Engine_ class to provide a norns interface:
{ https://github.com/antonhornquist/r/blob/master/lib/Engine_R.sc }

the “kernel / interface” structure makes for easier development away from the norns environment.

R is pretty complex. i can mock up a simpler example of just dynamically chaining a couple of effect synths in one engine.

it’s not necessary to put every synthdef / bit of functionality in its own class. if you do like to split things into many classes, it’s ok (and common) to put multiple related classes in one .sc file.

you don’t. supercollider compiles all classes in its include paths to bytecode when the interpreter is started. dependency cycles are not a problem, e.g. this is fine:

Foo.sc

Foo { 
  var bar;
  init { bar = Bar.new; }
}

Bar.sc:

Bar { 
  var foo;
  init { foo = Foo.new; }
}
1 Like