#9

dynamic FX!

i’m nervous about the complexity of treating AUX/INS like extra “engines” regarding the param exchange and additional application loading.

but i do like the idea of adding the possibility to switch between instances of built-in crone/faust FX. this seems like a great place for DSP extensibility in crone with minimal overall system complexity, if we give some thought to param management.

5 Likes
#10

Is there enough horsepower in Norns at this time to handle the sort of computational complexity being discussed here in a live environment? I’m all for ambitious software roadmaps but overall platform stability and hardware capacity are the other two legs of the stool. I could be way off so thanks for humoring me.

#11

i don’t believe anything in this proposal implies increased computational complexity per se.

(well, obvs if we add arbitrary FX algos then the cost of computing those is also arbitrary.)

we remove some architectural complexity by using static metadata files to describe parameters, rather than a dynamic descriptor table that matron and the engine environment (supercollider) have to collaborate in building at runtime over OSC. (the present situation - it’s scary and complex. has worked so far, but i’ll be happy to tear it out.)

we add some architectural complexity with the requirement to manage different DSP processes instead of just supercollider. this is minimized if we only have one process at a time and completely tear it down when switching engines.

as far as horsepower specifically, the nice thing about the architecture is that matron (lua), crone client (mixer, fx), softcut client, and the DSP engine(s) are each in separate processes, and we have 4 CPU cores. generally they are not gonna compete for cycles,

so, yes, arbitrary DSP engines need to be computationally efficient enough to run on one core without underruns, which is the same limitation presently applying to supercollider-based engines.

4 Likes
#12

Whew!

Arbitrary whew!

#13

I almost raised this in my enthusiasm-for-fx post above, as I could easily see system param / audio menus being clogged with a zillion hard to navigate parameters.

Perhaps “master end of chain fx” are limited to a set number of well chosen - even macro - params?

Or nav a level down (‘more…’) for detailed editing?

Lots of possibilities, but needs plenty of thought and discussion as mentioned. There is quite a lot of finger dancing already when nornsing.

#14

post promising to make dirge into an arbitrary effect if this gets implemented

6 Likes
#15

clarification, it will compile on linux.

on mac, CLOCK_MONOTONIC is missing from the POSIX implementation, so metro.c won’t compile or function. it needs a platform-specific shim using mach_time or something. (this SO post has some hints but is not a complete solution.)

on windows, i have no idea

1 Like
#16

My thought was more that the Lua level would have easy access to an expanded collection of baked-in effects instead of them being automatically part of the parameter menu, kind of like how softcut is now instead of the master effects.

I would imagine a call like

shinyReverb = NornsEffects.get("ShinyReverb")
shinyReverb.init()
shinyReverb.addAllParametersToMenu()

or

shinyReverb.addParameterToMenu("Decay")

That way, the script author can determine what gets exposed to the user on the parameter menu, and what is managed by the script itself, if that makes sense.

For the initial 3.0, I’m thinking that these could just be some C++ files that are baked-in like softcut instead of a quickly-expanding plugin library. The focus could be on well-curated effects so that we could have a flexible reverb, or a tape saturation buddy for softcut, etc.

5 Likes
#17

Hiya!

Design of how we’re to support multiple engine backends is well underway. There is quite some work to implement and test this thoroughly. To clarify, though, right now there’s no initiative taken to support running multiple engines (as in engine instances) at the same time. One script, one engine what we’re working on for 3.0… well, at least for now. :slight_smile:

@trickyflemming
Arbitrary effects as discussed here I consider to be a new feature request, which obviously would be super-awesome to have. This can be solved in various ways, but IMO has not been planned or prioritized for 3.0… yet. The only thing close to this right now is the R engine.

@bobbcorr
re: platform stability

One thing not yet mentioned in this thread is that we in 3.0 also will try to address a couple of serious issues with SuperCollider engines that happened as a consequence of breaking up the monolithic monome/dust repo - namely the class duplication problem. The idea we’re exploring for 3.0 is to move away from implementing engines as SuperCollider classes to implementing engines in interpreted sclang. This way, creating engines would be more like working in the SuperCollider REPL, so to speak, without recompilation of the SCClassLibrary and all the issues that it brings (… has anyone used Quarks? :exploding_head:). Interpreted sclang is also more similar to working with lua scripts. There are implications to this, of course, and we do not know if it will fly on the rpi (I’m wary of sclang performance). But if we can use interpreted sclang the big win is we will get away from a lot of engine installation issues and hassle users have been dealing with.

4 Likes
#18

I’ve been an advocate for smoothing the rough edges of products my entire career, so it made my morning to read this. However you accomplish it, making the process of loading, using, updating and managing scripts a simpler and less-prone-to-badness one is a big win for the entire community. Thanks again.

1 Like
#19

Super cool, and hopefully I’m understanding the intent of engines correctly but I mean it’s a linux box too so! I’d be excited to try to port astrid/pippi to a norns platform. The intention being for it to run asynchronously in the background and push buffers to a realtime thread.

Astrid, which is the interactive front end to pippi I use for performance etc already works like this and uses JACK so from the little I have read about norns it shouldn’t be too crazy to integrate directly?

Selfishly if astrid/pippi ran on norns and I can just run norns on a laptop or NUC or whatever if I don’t care about the GUI or I/O this would be even more fun to me.

Anyway, I’m excited about these developments which I am late to the party on!

#20

csound + faust + llvm

just voicing some vague interest in these since I don’t think anyone else has yet - I would love a way to write sample-level DSP on norns (C++ or faust would be fine) and I feel like it would be the best platform for building larger modular-type engines.

1 Like
#21

fwiw, its fairly straightforward to build and use custom supercollider UGens at the moment. you can use Faust and the faust2sc helper script if thats yr jam. (if you are looking to build something ‘modular’ it’s hard to see the benefit of reinventing the graph management wheel… i guess fun/ownership/learning are reasons.)

1 Like
#22

for sure, the only worry i’d have is performance. looks cython-based, maybe it’s fine.

1 Like
#23

I haven’t tested it on a raspberry pi in a long while. It’s slower, for sure. It would work best for async renders. (Eg events that can be delayed by seconds or more, not anything time sensitive.)

Edit: I just realized it’s possible to call cython from C, so I would assume I could create a lua interface for the library and skip the python runtime altogether… that could be fun and a better way to go about using pippi on raspberry pi.

#24

right, yea, this would actually probably work well for me

#25

in that case, have a look at norns/sc/wscript. it contains waf rules for building UGens and makes it basically trivial to add new ones.

since 2.0 we got rid of lots of custom ugen stuff so there is just the one (TrigPhasor, a pretty simple utility.)

i think i used faust2sc in this context with no trouble in the past. but if you are planning to use faust a lot, it might be worth getting comfortable with using a custom output template. (not hard.)

1 Like
#26

This may be out of the scope of this thread, but one thing that I would like is a way to define dependencies on things like node/npm or python/pip with minimum versions there - I’ve got some ideas (and some scripts) sitting on my norns that are more easily executed in something that makes doing a whole pile of http calls easily, and wraps them up in a nice interface. I don’t have a great way of distributing them though, since I don’t know what people will have installed on their norns.

Specific scripts I have in mind:
radio tuner that just jumps through random mp3 streaming radio
radio tuner that downloads a pile of junk via youtube-dl
one button upload of latest tape recording to soundcloud

3 Likes
#27

These sound VERY cool for use in something like Orca and Timber. Would it maybe be worth just listing the necessary dependencies in the Library posts for these?

1 Like
#28

Ability to run custom DSP plug ins sound rather amazing.

1 Like