Thanks for the heads up! It’s actually in the engine: https://github.com/antonhornquist/r/blob/master/lib/Engine_R.sc#L2127-L2196

… but wasn’t added to the list of specs in the r.lua library. Now fixed, pull the latest from the git repo to get the update.

1 Like

Nice!

I figured it’d been deprecated by MMFilter or something since I didnt see it in the r.lua libarary.

FWIW - here’s the thing I’m working on (an audio gating sequencer thingy):

11 Likes

Cool! :slight_smile:

The separate BP/HP/LP/BR filters will remain in the library even though a multimode-variant is in there. Reason they’re there is performance - the multimode verison runs all filters even though not all are used. So if you only need BP in a script where a lot of other modules are used it’s better to choose the BP one to conserve CPU.

It’s the same reason there’s Sine/Pulse/Sine/Tri oscillators and MultiOsc.

2 Likes

seeing a deluge of these messages in the SC tab in maiden:

"/" as delimiter for module input references is deprecated. Use "*" instead, like so: Delay*DelayTimeModulation.
"/" as delimiter for module input references is deprecated. Use "*" instead, like so: Delay*In.
"/" as delimiter for module input references is deprecated. Use "*" instead, like so: Delay*DelayTimeModulation.
"/" as delimiter for module input references is deprecated. Use "*" instead, like so: Delay*In.

Some of these I’m not using, so are they coming from the engine library?

Hi,

I’ve changed the syntax for inputs. See https://github.com/antonhornquist/r/blob/master/README.md#commands

Earlier, for connect and disconnect commands both outputs and inputs used the / delimiter like so:
connect Osc/Pulse Out/Left

This is now changed - * is the delimiter for inputs like so:
connect Osc/Pulse Out*Left

The earlier behavior still works, but is deprecated. That’s why SuperCollider posts these messages. Just change to the new delimiter and no deprecation warnings will be posted.

EDIT: Reason for the change is it makes the input and output references unique, which was not the case before.

/Anton

1 Like

Thanks!

Ok - to clarify (mostly for myself):

Outputs use / delimiter
Inputs use * delimiter

…and connections are in the order connect <Output> <Input>

(I think I had this backwards in my tired brain last night)

Correct. 20 characters

1 Like

Would a sample playback module be a possible addition?

And/Or would it possible to get the audio from TAPE as an input?

A sample playback module is in the works (SPVoice here https://github.com/antonhornquist/r/blob/master/lib/r.scd#L3912-L4128) . This module does not stream samples from disk, they need to be loaded to memory. A few additional engine commands have to be added for this to work (ie. at least readsample - in the works here https://github.com/antonhornquist/r/blob/master/lib/r.scd#L498).

EDIT: With SPVoice it is possible to read files recorded using TAPE and play them back. Right now there’s no possibility to feed TAPE output into engines, though, so as with any other engine R cannot use live TAPE output for processing. TAPE is a separate process (implemented in C++). With a bit of jackd plumbing it sounds feasible to route TAPE output to engines. @zebra or @tehn I don’t recall, has this feature been discussed?

/Anton

4 Likes

I’m wondering about new Clock coroutine options and how those might work to sync an LFO to global clock.

Would this be doable with the existing LFO modules?
(It’s late for me so I’m not quite piecing that together yet).

Hi,

I’ve not tried to sync LFOs with the Lua scripting layer in any way yet. Also, I unfortunately haven’t had the time to use the Clock coroutine functionality.

That said, regardless of the clock (this could be a metro too I guess) - if you know a “current tempo” and would like to sync on a certain beat/subdivision you might get something going by

  • continously updating the Frequency parameter of an LFO module to what is the “current tempo” (a BPM to LFO rate conversion would have to be made and Frequency would have to be updated when BPM changes)
  • resetting the LFO using the Reset parameter on certain beats/subdivisions.

Let me know if you need clarifications. Again - this is not something I’ve tested in practice but seems like the only reasonable way to get it to work since the LFOs - as all things R - run in audio rate as opposed to control rate on the SC side.

2 Likes

is there a way to tell if if a modules connection is a inlet or an outlet?

for example this code:

 function getModules()
  local loc = 1
  for k,v in pairs(R.specs) 
    do
    list_content[loc] = k
    loc = loc + 1
    print(k)
    for i,j in pairs(R.specs[k])
      do
       print('---' .. i)
    end
  end
end

outputs:


Amp

—Level

FShift

—Frequency

—FM

Decimate

—DepthModulation

—Rate

—SmoothModulation

—RateModulation

—Depth

—Smooth

is there a way to list if those are inputs or outputs? Maybe using “generateLuaSpecs”? Sorry I might be running before I can walk.

Thanks!
Eric

Hi Eric!

Your code lists module parameters, not inputs/outputs. This
is simply because that’s what has been generated as Lua specs to R.specs (using the generateLuaSpecs SC method).

You’re right in the need for other metadata Lua side though. It’s something I’ve been working on for some time. There’s a new way of defining modules with more metadata possible to specify SC side. So I now made a new update of r.lua covering inputs and outputs too. R.specs will remain as is describing parameter specs, for backwards compatibility. R.metadata, which I just added, contains more extensive metadata. Let me know if that helps (you’d have to pull the latest from the repo) for your use case.

BTW, thanks for referring to generateLuaSpecs - I just re-read and noticed a typo in the readme which I also fixed earlier today.

1 Like

Thank you for the information, and sharing the project, its very nice!

Question 1:
How would one go about adding a “Feedback” control for a Delay?

EDIT: Found Rymd and I’m trying to use that as an example of how to do feedback amount, but it seems a bit touchy so far and some gain values make it get louder each repeat (?)

Question 2:
What do you think about a LongDelay module with something like:

'DelayTime' -> (
    Spec: ControlSpec(1, 120, 'lin', 0, 4, "sec"),

I’m trying to add a LongDelay module by copying Delay in R.sc, but I can’t seem to get it to work. (even just copying Delay and changing just it’s name)

I get an error unable to create "Delay". invalid module type "LongDelay" in maiden when starting my test script. I’ve ;restarted SC after making changes to R.sc and setup an appropriate listing in r.lua. What else am I missing?

Is your code posted anywhere? Here’s a commit where I added a pink noise module. It’s a super simple example, but maybe it will be useful to see what was involved.

1 Like

@okyeron @Justmat

Hi! Very sorry, I’ve refactored R engine considerably but old left-overs are not removed yet and docs are not updated. Modules are now defined in the main r.scd file (yeah, it’s in one big file :slight_smile: ) :

See the stdModules array here:

3 Likes

Specifically, re your questions.

Question 1:
In Rymd I just loop back the audio with a gain stage in between. It is, of course, possible to add internal feedback in the Delay module (I guess using a local buffer would do). With an external path it’s possible to pass the signal that is fed back through additional modules - in Rymd there’s a filter in the feedback path, and IIRC the signals are being cross-fed left / right.

Question 2:
A module with longer delay makes sense. See above link for how modules now are created. The code alone likely will make sense (I’ll try to update the docs soon). Just make sure 120 secs do not allocate too much memory for the PI to handle.


By the way - to get a faster feedback loop I spent some time to create a “norns engine tester” kind of capability for prototyping scripts in SuperCollider on a regular computer. This only covers the subset of norns features I actually use in my scripts and is currently undocumented + unsupported.

Anyhow - with this you should be able to run a bunch of my scripts (ie. bleeding edge versions moln, rymd, bob and skev) on the computer. Just open the files and evaluate the content.

3 Likes

Thnx!

I’ll look at r.scd tonight.

What would be a quick/easy way to determine this on the pi?

I know top will show me cpu use…

(120 was just a arbitrary number - 60 may be plenty?)

Welp… looks like anything over 20 seconds barfs with this:
JackDriver: exception in real time: alloc failed, increase server's memory allocation (e.g. via ServerOptions) (on Pi4 2GB). Have not attempted to change via ServerOptions.