soeren

Hello everyone,
I hooked up a rotary encoder as shown in here
http://farhek.com/jd/c1f1971/studio-rotary-encoders/31y79t/
Then I compiled @bela_robert code ,but nothing was printed out. I temporally switched from digital to analog pins so I can use the scope example to visualise the incoming signal , it responded to push and rotation as expected, so i guess there is nothing wrong with the hardware . Am I missing something with the code? Shouuld i modify it?

P.S. I used the pins P8_08 and P8_07 for the rotary.

Then of course, there is the analog engineer's take on this stuff (this pretty much was inspired by analog circuits designed to implement an ADSR):
https://github.com/transmogrifox/transmogriFX_bela/blob/master/src/adsr.cpp

It looks like this:

Below is the working part of the code with more comments added. Notice it uses first-order IIR filters instead of exp() or pow() functions. The exponential function occurs naturally due to recursion. All the setup code is related to scaling coefficients to the correct values so the recursion works properly.

void
adsr_tick_n(adsr* ad, float* output)
{
//The ad->NS comes from the block size set up in the creation of this struct.
//When used in Bela, this is the "n" variable.
    for(int i = 0; i < ad->NS; i++)
    {
       //These next couple of blocks are for transitioning from one state to the next.
        if(ad->trig_timer < 1)
            ad->state = ADSR_STATE_RELEASE;
        else if (ad->trig_timeout > 0)
            ad->trig_timer--;
        //if trig_timeout < 0 then sustain forever

        if( (ad->state == ADSR_STATE_RELEASE) && (ad->trig_timer > 0) )
        {
            ad->state = ADSR_STATE_ATTACK;
        }
      //The switch statement below evaluates whether attack, decay, sustain, or release state should be computed
        switch(ad->state)
        {
            case ADSR_STATE_RELEASE:
                ad->sv *= ad->rls; //Just multiply the current value of "sv" by a number less than one for every sample.
            break;

            case ADSR_STATE_ATTACK:
                if(ad->sv >= ad->amplitude)  //we trigger state change when state variable "sv" gets to max amplitude
                {
                    ad->sv = ad->amplitude;
                    ad->state = ADSR_STATE_DECAY;
                }
                else
                	ad->sv = ad->sv + ad->atk * (ad->pk - ad->sv);  //This is a first-order IIR filter, behaves like an analog RC filter driven with a step input "pk"
            break;
            
            case ADSR_STATE_DECAY:
                ad->sv = ad->sv + ad->dcy * (ad->sus - ad->sv);  //This also is a first-order IIR, driven with step input "sus"
                if(ad->trig_timer == 0)
                    ad->state = ADSR_STATE_RELEASE;  //Redundant but paranoia safety (always return to a known state)
            break;

            default:
                ad->state = ADSR_STATE_RELEASE;  //more paranoia
            break;
        }
        output[i] = ad->sv;  //each time through the loop add the current sample to the output buffer
    }
}

Then on every block you multiply the buffer you send in for "output" with your sine tone.

Here is an example of where this is used in Bela for controlling a filter cut-off frequency:
https://github.com/transmogrifox/transmogriFX_bela/blob/master/src/sample_hold_modulator.cpp

It's complicated to sort through that whole blob, so below shows where the ADSR struct is used:

sh_mod*
make_sample_hold(sh_mod* sh, float fs, int N)
{
.
.
.
sh->ad = make_adsr(sh->ad, fs, N);
.
.
.
sh->adsr_env = (float*) malloc(sizeof(float)*N);
.
.
.
for(int i = 0; i < N; i++)
    {
    	sh->adsr_env[i] = 0.0;
        .
        .
        .
}
.
.
.
//Initialize ramp rates
    adsr_set_attack(sh->ad, Trate/8.0);
    adsr_set_decay(sh->ad, Trate/8.0);
    adsr_set_sustain(sh->ad, 0.36);
    adsr_set_release(sh->ad, Trate/4.0);
    adsr_set_trigger_timeout(sh->ad, 0.5/rate);
.
.
.
}
.
.
.
void
run_sample_hold(sh_mod* sh, float* output)
{
.
.
.
adsr_tick_n(sh->ad, sh->adsr_env);
.
.
.
if(sh->en_adsr)
output[i] = sh->adsr_env[i];
.
.
.
}

This doesn't back it up to the Bela render() function, but my code has to be tracked back to the render() function via the envelope filter code:
https://github.com/transmogrifox/transmogriFX_bela/blob/master/src/envelope_filter.cpp

void
envf_tick_n(env_filter* envf, float* x, float* e)
{
.
.
.
//TODO: move to env_filter struct
run_sample_hold(envf->sh, envf->sh_buff);
.
.
.

Then finally envf->sh_buff gets applied to something (modulating the filter)

		//limit to range 0 to 1 and apply to filter frequency setting
		ei = clamp(ei*envf->sns*envf->ishmix + envf->sh_buff[i]*envf->shmix);
envf->frq[i] = envf->depth + envf->width*ei;

And envf->frq[] is a buffer to identify a time-varying cut-off frequency

   //Run the state variable filter
svf_tick_fmod_soft_clip_n(envf->svf, envf->y, envf->frq, envf->N);

So now where/how is this called from render()?
https://github.com/transmogrifox/transmogriFX_bela/blob/master/src/render.cpp
First you have to see what was done in setup:

bool setup(BelaContext *context, void *userData)
{
	gAudioFramesPerAnalogFrame = context->audioFrames / context->analogFrames;
	gifs = 1.0/context->audioSampleRate;
	gNframes = context->audioFrames;
	
	ch0 = (float*) malloc(sizeof(float)*context->audioFrames);
       ch1 = (float*) malloc(sizeof(float)*context->audioFrames);
.
.
.
	//Envelope filter
	ef = envf_make_filter(ef, context->audioSampleRate, gNframes);
	gMaster_Envelope = (float*) malloc(sizeof(float)*gNframes);
	for(int i = 0; i<gNframes; i++)
gMaster_Envelope[i] = 0.0;
.
.
.
}

Then here is render()

void render(BelaContext *context, void *userData)
{
	format_audio_buffer(context, ch1, 1);
	format_audio_buffer(context, ch0, 0);
	
envf_tick_n(ef, ch1, gMaster_Envelope);
.
.
.
}

I may have gone overboard in explaining the connection back to render(), but the first step from adsr_tick_n() gives the algorithm. It's pretty simple for me because it thinks like I do, but putting myself in the place of trying to digest some other person's code...it's probably more horrible than the author you're referencing

Anyway let me know if you want some more streamlined examples. The adsr code is a complete C-style struct that implements an ADSR the way an analog synthesizer does it. I haven't benchmarked it, but I expect the code is reasonably efficient. It certainly doesn't make a noticeable increase on CPU usage when I switch between sample/hold filter options. Pretty minimal compared to the double-sampled state-variable filter it's used in

The range makes no sense to me, so good idea to ignore it

If you are looking for some good books on this sort of thing have a look at the two books by Will Pirkle.

The "designing software synthesiser plug-ins in C++" book might be well worth a look.

Hi,

Your render function is not quite right, remember the render function should process context->audioFrames samples, in the original code there was:

for(unsigned int n = 0; n < context->audioFrames; n++)
{
  // do stuff here
}

In your code you are processing 3 seconds worth of samples, which is quite a lot more.

So make your k variable global and initialise it to 0 in setup()

Then in the audio loop from the original example you can put your code in, don't use a loop for k, just increment k each time round the original loop.

If you are still stuck after trying I can give you some more pointers...

soeren how do you go about making an auxiliary task that takes argument(s

AuxiliaryTask Bela_createAuxiliaryTask(void(*)(void *) callback, int priority, const char * name, void * arg )	

The last argument (optional) passed to Bela_createAuxiliaryTask() is a void* that is then passed as the only argument to the function.
See the docs.

If you want to pass an argument other than a void* then you should pass it (or a pointer to it) and then cast it accordingly. For instance the below code:

void myCallback(void* arg)
{
  float param = *((float*)arg);
  print("param: %f\n", param); 
}

bool setup(BelaContext* context)
{
  float param = 123;
  AuxiliaryTask task = Bela_createAuxiliaryTask(myCallback, myPriority, myName, (void*)&param);
  Bela_scheduleAuxiliaryTask(task);
}

should print 123 (untested).

Just one follow up question: we do agree, that putting something in an aux task equals putting it into a different thread - right?

Yes it does. An AuxiliaryTask is a different thread.

Assuming that your

			//setFreq(500 * (time + 2), 0);

is actually

			setFreq(500 * (time + 2), 0);

, here is your problem: you are doing an infrequent but expensive computation in the audio thread while your CPU is already pretty busy, thus causing glitches.

Setting the frequency of a few hundred oscillators at once can be pretty expensive (especially considering it contains a call to random()). So let's say that on average your audio thread takes 70% of the CPU time: on that one audio callback where you are updating the frequency, you may be using more CPU time than the you have available ( > 100%) and therefore glitch. Note that you would not see such spike in the CPU usage from the CPU meter, because that shows the average CPU usage, but you are getting dropouts on a peak of usage.

By updating the frequencies in a separate thread, you guarantee that no such glitch occurs, as the CPU time spent to update the frequencies can take the time needed without hanging a single audio callback.

This is a very timely question: the talk I gave today at the ADC explains this problem in detail and I hope you will find it useful (starts at 5h32m23s):

soeren EDIT: is best practice to just always put everything non-audio related into auxiliary tasks? If that is the case,

In principle yes, it is good to put everything non-audio related into an aux task. However, some audio-related but non time-critical stuff (like in your case) can go in a separate thread, too. Hopefully the last part of the talk clarifies that.

soeren how do you go about providing an auxiliary task with a BelaContent object ?

You don't! A BelaContext* is only valid in those threads that call setup(), render() and cleanup(), and only for the lifetime of the function itself. This means that you should not make a copy of a BelaContext* to use later or to pass it to another thread. If you want to access elements of the BelaContext* from an AuxiliaryTask (e.g.: for getting an input value or writing an output value), then you should do so by reading/writing a shared resource (e.g.: a global variable) from one thread and reading it from the other. For instance, if you want to write to an analog out a value computed in an auxiliary task you would do:

float gAnalogOutValue = 0;
int gAnalogOutChannel = 3;
void auxiliaryTaskCallback(void*)
{
  gAnalogOutValue = random() / (float)RAND_MAX;
}
void render(BelaContext* context)
{
// ...
  analogWrite(context, n, gAnalogOutChannel, gAnalogOutValue);
// ...
}