Can’t change frequency of rnbo saw

[dietcv]

Hey, I have successfully build the rnbosaw. It does make sound. But you are not able to change the frequency of the ugen inside sc.

[x37v]

The example here is very basic, it doesn't expose the ability to change frequency, you'll have to add that yourself

[dietcv]

Thanks for the clarification. I thought this was intended with this simple example because the ugen has a frequency argument.

[x37v]

actually, i see that there is a creation arg that specifies frequency there, but no dynamic frequency setting.. it looks like that isn't used but you're correct that it is confusing. I'll look into using that value.

[dietcv]

Awesome, thanks alot :)

[dietcv]

There are some additional things which i found out:

• the ugen is not normalized between -1 and 1 and has some weird jitter. EDIT: The standard blocksize in SC is 64 samples. If you set it to 512 samples with s.options.blockSize = 512; when booting the server (buffer size of the RNBOSaw.cpp file), then you dont have any jitter. So it would be about setting the buffer size dynamically to the initialised blocksize in SC, same with the samplerate i guess. I have seen the comment about that in the .cpp file.
• the rnbo patch does output the sig (out~ 1) and the phase (out~ 2). I would expect that these could be accessed in sc via RnboSaw.ar(freq)[0] and RnboSaw.ar(freq)[1], but thats not the case. You cant access the different outputs at all.

[dietcv]

My expectation was just wrong. I thought this could be used as a blueprint for exporting RNBO code to SC without having to write C++.

[x37v]

I think this is just a very minimal proof of concept, but maybe @isabelgk has more ideas about that.
since the .sc file exposes frequency though, i do think that it should be used

[dietcv]

Thanks you very much for the update :). When passing an initial value for freq it is playing the RnboSaw at exactly that frequency. You can however not change it dynamically for example with MouseX:

(
{
	var freq = MouseX.kr(20, 4000);
	//var sig = RnboSaw.ar(freq.poll); // freq cant be changed after beeing initiliased
	var sig = RnboSaw.ar(220);
	sig!2 * 0.1;
}.play;
)

I can imagine that for beeing modulated at audiorate (FM) it would need additional treatment. Maybe i can mobilize some people from the SC community to work on further details. I know that there is some interested in a working C++ template for exporting RNBO code to SC. Thanks alot :)

[x37v]

Yeah, I just set it up as an initial frequency, not something that you can modulate.
making a .kr rate control is doable, but you'd want a different approach for audio rate modulation, in rnbo that would be another in~

[dietcv]

thanks :) Im just curious, would it be possible to write a template in C++ with a limited amount of effort, so you could export arbitrary RNBO code to SC or should i forget about that? Right now it seems to include too many cases to handle and i guess i wont find people familiar with max/gen/rnbo, C++ and supercollider to make it work.

[x37v]

limited amount of effort I'm not sure about.. but I do think it should be possible with some effort.

One thing that might be interesting for you or anyone else wanting to try is the RNBOMetasound implementation, which builds out a number of plugins based on rnbo exports it finds in a specific directory. It uses the Unreal build system, but you could probably do all that it does directly with cmake, and also generate your .sc files from the rnbo description.json files.

[dietcv]

Would you know if it is necessary to declare a buffer, i guess for every control block, like its done in the rnbosaw example?
There is an example available for creating SC plugins and i cant find such a buffer declaration there:
https://github.com/notam02/supercollider-plugin-tutorial/blob/main/plugin-code/plugins/RampUpGen/RampUpGen.cpp