analogue01

I really like the sound of the ola.granular patch in the gen examples and would love to adapt it for my own uses. However, I'm not yet very good at reading gen code. Can someone help me undertsand what's going on?

Specifically, I/m wondering why I get clicks/artifacts sometimes when frecency is low and the density is high (and also sometimes when there "ahead" param has a large value). I can still hear the windowing working, too... hmm

I really like the sound of the ola.granular patch in the gen examples and would love to adapt it for my own uses. However, I'm not yet very good at reading gen code. Can someone help me undertsand what's going on? 

Specifically, I/m wondering why I get clicks/artifacts  sometimes when frecency is low and the density is high (and also sometimes when there "ahead" param has a large value). I can still hear the windowing working, too... hmm

I really like the sound of the ola.granular patch in the gen examples and would love to adapt it for my own uses. However, I'm not yet very 

ola-granular-help-me-understand

The way the OLA (overlap-add) examples work is by using a kind of look-ahead buffer to write the grains into, which is constantly read and erased. Every time a new grain is spawned, the waveform of the entire future grain is written into this buffer, using overlap-add (so that other future grains are not overwritten). This all happens in the codebox. It's a gen~ patcher, so the codebox runs on every sample of the real-time audio process. It first checks whether on the current sample, we should spawn a new grain. Then it has a for-loop to write each successive sample of the grain, including computing its window, its content, the stereo pan, etc., and where in the overlap-add buffer it should be written. The parameters  specify the density of grains, their duration, and other properties for the synthesis of each one.

A separate process continuously reads out the result of this buffer, erasing as it goes (a bit like a tape head). This is the max patching code to the right of the codebox.

The clicks when density is high and frequency is low (duration is long) will be because of overloading the audio thread in this case (making dropouts). There's lots of different ways of writing granular synths, and OLA is just one of them. The gen~ examples are particularly well-suited to the use of very short duration grains. As the grain duration gets bigger, there's a higher chance of it causing a dropout, as it is trying to compute and write a large number of values within a single audio thread buffer (computing the entire grain in one shot). For working with longer durations you'd probably want to use an algorithm that keeps track of active grains and synthesizes them in chunks as time passes instead. The code for that would be longer and harder to understand, which is why I thought that the simpler one-shot OLA method would be better for the gen~ examples folder.

Hope that helps!

I don't suppose you have any references for the algorithm you describe in the latter half of your reply?

It's basically the same as a note allocator connecting two parts: a note/grain scheduler, and the note/grain algorithms themselves. 

For synchronous granular, the scheduler will be something like a counter or phasor, triggering a new note each time it cycles. For asynchronous, you could use a probability test, e.g. [noise] -> [abs] -> [< probability/samplerate], where probability is a [param] representing the chance per second to spawn a grain. In both cases, the output is a single-sample trigger to request a new note/grain.  

For the note/grain events themselves, you could do them as grainplayer subpatchers/abstractions, with a bunch of them in the gen patcher (this defines your maximum polyphony, or maximum grain overlap). Each event will have an envelope player, driven by some accumulator such as [counter] or [+=] routing into the envelope function. You can use the position of this accumulator to check whether the note/grain is "busy": that is, if the accumulator position is greater than zero and less than the grain duration. 

For the allocation itself, one way I have been doing this is to pass the new event trigger to the first grainplayer subpatch, and internally, if the note is busy, it passes the trigger back out, and on to the next grainplayer subpatch. If the grain is not busy, it will reset its grain counter to zero and set the grain parameters, thus starting a new grain.  

The outputs of all the grain subpatchers are then just added together and output. 

Thank you that's a good explanantion I'll give it a go. 

ola.granular help me understand

yaniki

Do we have a section somewhere in the gen~ documentation that discusses using arguments that enable the creation of structures that allow the use of #0 and/or -- arguments to create local references, similarly to using the mentioned arguments for e.g. local send/receive connections?

Let's say I have an abstraction, in it a buffer~ object, which is also referenced by the code placed in gen~ (in the same abstraction). I use "--#0_something" in the name in buffer~ (to behave like a "locally" named object from both MaxMSP and M4L). Now how do we translate this into a "link" to buffer~ inside gen~.

I will be grateful for your suggestions and tips.

Dear Friends

Do we have a section somewhere in the gen~ documentation that discusses using arguments that enable the creation of...

0-andor-arguments-and-gen

#0 and/or -- arguments and gen~

Yueting Wu

I am trying to create a readable wavetable within gen~ using the data object 

since I need the patch to work for Oopsy daisy, the patch cannot refer to any external buffers in max

The closest answer I was able to get was this post:

https://forum.electro-smith.com/t/oopsy-wavetable-synth-without-reading-from-sd-card/3736

--using the codebox object to manually input sample values of waveforms into the data object 

The OP's patch (basic waveform oscillator) works, but when trying to add new waveforms to the patch, I ran into issues: 

I obtained sample values (256 samples) of the single-cycle waveforms from 

https://www.adventurekid.se/akrt/waveforms/

 and input those values into the codebox, I received the following errors

I double checked and the list of values I put in indeed contained 256 items, so I am confused about why it "exceeded the maximum of 256"...and then I checked the amount of items in the lists that OP put in, and they actually contained less than 256 values (250&248 respectively)...so I just deleted the last few values from my list....the error disappeared but still there is something wrong:

It seems like it's reading the new waveform I put in twice as fast as it should????

I am very new to all this and not sure if I am doing something wrong here,  or if there is any other ways of creating a wavetable completely within gen~ 

*"Datawavetable" contains OP's waveform, "datawavetable2" contains the waveform I tried to put in 

hi ! 

I am trying to create a readable wavetable within gen~ using the data object 

since I need the patch to work for Oopsy daisy, the...

writing-waveforms-into-data-object-in-gen-without-referring-to-an-external-buffer-in-max

writing waveforms into data object in gen~ without referring to an external buffer in max? 

PlasticDSP

For a simple Onepole LowPass filter made with a history and a linear interpolation function, what's the best way to implement resonance?  

Filter Question 

For a simple Onepole LowPass filter made with a history and a linear interpolation function, what's the best way to...

lowpass-filter-design

LowPass Filter design

Tarik Barri

I must be overlooking something insanely obvious, but I can't figure out what.

...fails to compile, and gives me the error message:

gen_domain: dsp.gen: [string "gen2.dsp.Model"]:1687: attempt to index local 'instance' (a nil value)

(EDIT - this refers to the 'gen' object, not the 'jit.gen' object)

I've reproduced on several max versions and two computers, but can not find this issue mentioned anywhere online.

Any hints as to what's going on would be greatly appreciated

I must be overlooking something insanely obvious, but I can't figure out what.
This gen code:

getOne() { return 1.0; }
getOneIndirect() { return getOne(); }
if (getOneIndirect() == 1.0) {
  out1 = 1.0;
}

...fails to compile, and gives me the error message:gen_domain: dsp.gen: [string "gen2.dsp.Model"]:1687: attempt to index local 'instance' (a nil value)

(EDIT - this refers to the 'gen' object, not the 'jit.gen' object)
I've reproduced on several max versions and two computers, but can not find this issue mentioned anywhere online.

Any hints as to what's going on would be greatly appreciated
-t


I must be overlooking something insanely obvious, but I can't figure out what.
This gen code:
getOne() { return 1.0; }
getOneIndirect() { ... 

impossible-to-use-returned-value-from-function-in-if-statement

Hi Tarik,

I just added an else block and it works fine. 

I see, it's the "jit." that made it compile, not the 'else' statement.

The moment I remove the "jit." prefix and it becomes a regular 'gen' object, it stops compiling. So without wanting to jump to conclusions, I am tempted to go with the hypothesis that 'gen' is basically broken for now?

gen~ (with the tilde) seems to be slightly more robust than gen, but also this fails to compile when I get a bit deeper into conditionals:

and here's another amazing bug. Once this empty for loop is present, the output simply stops functioning (in both gen and gen~), so that this two line code doesn't work.

for(index=0; index < 1; index+=1) {}
out1 = 1.;


I can't possibly be the first one to run into all this weirdness, so maybe someone who's gone through this can tell me how they deal with these issues? 


Hi Tarik! 

I copy pasted your code into a codebox in jit.gen and it gives me exactly the output you would expect, without compilation errors. 

In "gen" instead it gives me the error you mentioned. 

Sounds like a bug, I will report it

Hey Tarik, so great to see this discussion here, my 2cents:
They do indeed need to work on making the max-window error messages from gen~/gen/jit.gen a bit more useful/helpful to us 🙏

seems like your code should work, i even tried adding a superfluous argument to the functions like the 'p' in the functions for Gregory's article here, as well as tried saving to a .genexpr file and instantiating using 'require'(thinking maybe it might compile differently when in an extraneous .genexpr file), still didn't work, even though Gregory's functions seem to have the same basic structure:
https://cycling74.com/tutorials/gen~-for-beginners-part-7-creating-reusable-tools

(also tried all those steps in both gen and gen~, couldn't get it to work)

i do know that 'gen'(without the tilde) handles scheduling and memory differently('gen' needs to be triggered from outside, or have internal metro on using '@active 1'... also cannot use things like 'buffer' but still can use 'data' instead), so maybe better off trying things in gen~ first.

i dunno... i tried, hopefully it at least helps whittle out some testing(maybe also posting Gregory's article can help you find some thread of similarity to follow).

Thanks both!!

I've now found that if I take the functions of which I want to test their outputs in an 'if' statement, and store the results of these functions in a 'History', I can use these functions. So:

getOne() { return 1.0; }
getOneIndirect() { return getOne(); }

History enableFunction(0);
enableFunction = getOneIndirect(); 
	
if (getOneIndirect() == 1.0) {
  out1 = 1.0;
}

...and if I want to do this with functions which take variable arguments, I need to use these same variable arguments when storing the results in the 'History', otherwise it will still fail.

The thing that most confuses me about this all though is not the bug itself, but the fact that it seems as if I'm the first one to ever try using returned function values in an 'if' statement. Which surely can't be true. I'm not that totally unique and special, or...?

the reason why your genbug2 patch creates silence is due to the code generated from your GenExpr code inside the Codebox - whereby its not yours code fault.

If you open the "code" sidebar of the gen (gen~, jit.gen, jit.gl.pix) patcher - the stylish C in the right hand toolbar -  you can see that the "code generator" has set out1 & out2 to 0 ... hence silencio ;-).

I also currently experience "gen code generation" weirdness, where an else block is just "optimised away", but that happens in the jit.gen.

But I guess, wheter audio or video domain, there is only 1 code generator that not only translates the "normal" gen operator patches, but also the GenExpr Code we type into Codebox into an intermediate GenExpr Code that its visible in the "code sidebar".

So if you experience weird stuff, the code sidebar is the place where you might detect THAT something weired / wrong was generated from your code.


Yes actually I noticed this too and this can help indeed. Not with the other errors unfortunately. But this 'history' hack I described above seems to make things work... for now...

Impossible to use returned value from function in if-statement?

I'm building a little granular synth with gen~, and I cannot seem to be able to build the grains using a function in a for-loop, while calling the same function 30 times (with a manually set instance number) works.

l, r = make_grain(0, c, smpl, size, position, pch, spread, spray, stereo_spread);

    l, r = make_grain(1, c, smpl, size, position, pch, spread, spray, stereo_spread);

        q, w = make_grain(v, c, smpl, size, position, pch, spread, spray, stereo_spread);

If I turn the call in the for-loop into this...

q, w = make_grain(0, c, smpl, 300000, position, 0.03, spread, spray, stereo_spread);

...I at least get some audible output. But setting the 0 back to v makes it go silent again, and the size and pitch parameters have to be set to very different value ranges than are otherwise defined somehow.

Hi all, long time no post.
I'm building a little granular synth with gen~, and I cannot seem to be able to build the grains using a function in a for-loop, while calling the same function 30 times (with a manually set instance number) works.
See the attached post.

So this works:
	out_left = 0;
	out_right = 0;
l, r = make_grain(0, c, smpl, size, position, pch, spread, spray, stereo_spread);
	out_left += l; d
	out_right += r;
	l, r = make_grain(1, c, smpl, size, position, pch, spread, spray, stereo_spread);
	out_left += l;
	out_right += r;
	// ... and so on, times 30
But this doesn't:
	for(v=0;v<30;v+=1) {
		q, w = make_grain(v, c, smpl, size, position, pch, spread, spray, stereo_spread);
		out_leftt += q;
		out_rightt += w;
	}
If I turn the call in the for-loop into this...
q, w = make_grain(0, c, smpl, 300000, position, 0.03, spread, spray, stereo_spread);

...I at least get some audible output. But setting the 0 back to v makes it go silent again, and the size and pitch parameters have to be set to very different value ranges than are otherwise defined somehow.
What am I missing?

Hi all, long time no post.
I'm building a little granular synth with gen~, and I cannot seem to be able to build the grains using a ... 

granular-synth-function-in-gen-does-not-work-with-for-loop-but-works-without-it

I suspect the problem will be inside make_grain() -- it probably has some state such as a History, or some stateful operator such as a phasor() or cycle() or accum(). 

Here's a simple example to illustrate the root cause:

for (i=0; i<10; i+=1) {
   x = accum(y);
}

This code is ambiguous: Does this mean we have 10 accumulators, or does it mean we have one accumulator we call 10 times?  Both are quite reasonable assumptions for different use cases. 
The way gen~ interprets it, we have one accumulator that is called 10 times.  (The reason why we opted for that interpretation is partly to prevent needing to allocate memory in the audio thread, which is generally a bad idea.)

It matters because accum() has an internal state -- the current running sum. If you had 10 accumulators you need 10 running sum states (10 numbers stored in memory). If you have 1 accumulator called 10 times, you only need 1 number stored in memory. 

Translated to your case: in the for loop, you have 30 calls to make_grain(), not 30 copies of make_grain(). Whatever internal state you have in make_grain(), it's shared between all 30 loop iterations. 

There's two ways to work around this. One is to just make 30 copies of your make grain patcher, or 30 calls to make_grain() as you did -- that ensures that the internal state of each one is distinct. 

The other is to pass the state into the make_grain() function -- that may be more fiddly to implement, it depends on what make_grain() is doing. 

(Well there's a third option too -- which we explored in Ch10 of the GO book, where each grain is created all at once and written into an output buffer/data -- that works well so long as the grains are very short.)



Cool, a response from Dr. Gen himself, thank you for the insights.
I would have never thought that there would be an internal difference between manually calling a function twice and doing that from a for-loop. Since I want to control the number of grains from outside of the gen code, the manual calling does not seem practical (or elegant).

See below for my make_grain(). From your explanation it seems the problem is with delta(), right?

make_grain(voice, gcount, buf, gsize, gposition, gpitch, gspread, gspray, gstereo_spread) {
	trig = delta(gcount == voice) == 1;
	icount = min( counter(1, trig), latch(gsize, trig) ); // counter resets when trig is nonzero. Latch passes gsize when trig is nonzero
	pos = latch(gposition + (noise() * gspray), trig); 
	pos *= dim(buf);
	sprd = noise() * gspread;
	sprd = pow(2, sprd);
	i = pos + icount * latch(gpitch, trig);
	amp = hann(icount, latch(gsize, trig));
	smp = peek(buf, i, boundmode="wrap", interp="cubic");
        grain = amp * smp;
 
	pan_left, pan_right = pan(gstereo_spread, trig);
 
	grain_left = grain * pan_left;
	grain_right = grain * pan_right;
 
	return grain_left, grain_right;	
}

If the internal state of delta() persists between iterations in the for-loop, trig is not going to be high as much as it needs to be.
So perhaps I could manually store the outcome of gcount == voice for each grain using a Data object with as many samples as there are grains, and then run my own delta operation?

I also looked at the ola gen example, but would have to modify it a bunch because I want to allow long grains while retaining responsiveness in shorter times than the grains may be long. Following your earlier comment about ola somewhere in the forum, I would need to make a scheduler that writes to the ola buffer in chunks instead of the entire grain.

All of the latch operators in that function are also stateful (they hold on to the previous value), and also the counter.  
Since the latches are all driven by the trig, they are basically holding the per-grain parameters. The counter is just counting samples from the grain start, right?  You could work around that by having a global counter (or just using the `elapsed` operator), and storing the grain start time. 

So  your Data would need to store all of these per-grain parameters, including the grain start time. 

If you have, say 4 per-grain parameters, and up to 30 grains, you could store it all in a [data grainparams 30 4]. 

Then you can pull out all the parameters in a one-shot call like this:

make_grain(voice, buf, gstereo_spread) {
  start, pos, gpitch, gsize = peek(grainparams, voice, channels=4);
  icount = elapsed - start;
  // etc. 
}

Then you can have another function (start_grain()) that would configure the parameters for a new grain, including setting the start == elapsed, and writing into the data

poke(grainparams, elapsed, voice, 0);
poke(grainparams, position, gposition + noise() * gspray, 1);
poke(grainparams, elapsed, gpitch, 2);
// etc.

BTW a tip for debugging:  use a buffer~ first so you can actually see what the data looks like.  In the max patch, a [buffer~ grainparams @samps 4 30], and use [waveform~] objects to look at the data. In the gen~ patch, [buffer grainparams]. 
It's easy to then swap that out for [data grainparams 4 30] later once you know it is working ;-)

Granular synth function in gen~ does not work with for loop but works without it

Massimiliano Cerioni

I needed to make an accurate latency test of my system, so I took inspiration from the old MSP latency test patch under 

 folder and built an alternative version in gen. There were a couple of active discussions 

, from which I took the threshold trick that Graham implemented.

I needed to make an accurate latency test of my system, so I took inspiration from the old MSP latency test patch under...

a-new-io-latency-test-patch-made-in-gen

A new IO latency test patch made in gen

Sébastien Gay

The "Like lores~" gen~ example uses a [phasor~ 150] as input. Comment says that incoming signal has to be harmonically rich. I believe I understand why. But what is the need to have it x2 and then -1 ? As far as harmonics are concerned, I see no significant impact on the spectrum ?

image.png

The "Like lores~" gen~ example uses a [phasor~ 150] as input. Comment says that incoming signal has to be harmonically rich.  I believe I understand why. But what is the need to have it x2 and then -1 ? As far as harmonics are concerned,  I see no significant impact on the spectrum ?

The "Like lores~" gen~ example uses a [phasor~ 150] as input. Comment says that incoming signal has to be harmonically rich. 

like-lores-gen-example-why-is-phasor-input-2-and-1

This is to increase the gain by 6dB and then remove the DC offset. You want the signal to be between -1 and +1 instead of between 0 and 1.

"Like lores~" gen~ example : why is phasor input *2 and -1 ?

cocamon

Does anybody here have a functioning approach for syncing data between a multislider and a buffer~ inside of gen~? 

The syncing case I'm struggling with at the moment occurs when I try to resize the sequence length to a value that is greater than the current value. With the naive approach of multislider always writing to buffer that means that its impossible to preserve data from longer patterns (for example returning to a gate pattern with length 16 after one of length 8).

On the other hand if I avoid resizing the buffer and dump its data into the multislider each time I increase the sequence length, I run into the issue of narrowing down exactly that case to avoid creating a feedback loop where its unclear which of the two objects has the correct state

So, has anyone found a workaround to avoid maintaining both a buffer~and a multislider to make editable sequences in gen~? Or can anyone think of an elegant algorithm to determine when the multislider should write to the buffer and when the buffer should write to the multislider ?

Hi folks,

Does anybody here have a functioning approach for syncing data between a multislider and a buffer~ inside of gen~?     

The syncing case I'm struggling with at the moment occurs when I try to resize the sequence length to a value that is greater than the current value. With the naive approach of multislider always writing to buffer that means that its impossible to preserve data from longer patterns (for example returning to a gate pattern with length 16 after one of length 8).
 
On the other hand if I avoid resizing the buffer and dump its data into the multislider each time I increase the sequence length, I run into the issue of narrowing down exactly that case to avoid creating a feedback loop where its unclear which of the two objects has the correct state

So, has anyone found a workaround to avoid maintaining both a buffer~and a multislider  to make editable sequences in gen~?  Or can anyone think of an elegant algorithm to determine when the multislider should write to the buffer and when the buffer should write to the multislider ?




Hi folks,

Does anybody here have a functioning approach for syncing data between a multislider and a buffer~ inside of gen~?     

The ... 

gen-buffer-and-multislider-sequencer

On the other hand if I avoid resizing the buffer and dump its data into  the multislider each time I increase the sequence length, I run into the  issue of narrowing down exactly that case to avoid creating a feedback  loop where its unclear which of the two objects has the correct state

sounds like a problem that could be solved by instituting some sort of Model-View-Controller paradigm(preferably, the 'model' would be in the event realm(not buffer))... perhaps then, you could define your multislider as 'controller', and buffer as 'view' or vice versa...
one way to do this is simply to instantiate a separate data-space for the model(could be anything, even a dict or coll, to store the multislider-like data), then update both the multislider and buffer, only as needed, using data from that space. hard to describe(without seeing your patch), but hope it helps to make a little more sense.

I don't know if this helps for your use-case, but quite often in these situations instead of a multislider I use a waveform~ with the UI mode set to "draw" -- it offers a very similar interface, but you are directly modifying the buffer~ data itself.
You can set the draw mode to clip. You can also zoom the waveform~ view to show only a sub-region of the buffer~. It is pretty powerful. 

waveform also offers you a rangeslider functionality in addition. i´ve used this for years before switching to lcd.

it will require a buffer of the right length, but it doe not reqire DSP ON to output mouse movement.


thank you to everyone for their replies. Graham, your suggestion is pretty much exactly what I'm looking for.



Gen~ buffer~ and multislider sequencer

Joji Iwasaki

Background: I was trying to write a binary search algorithm in GenExpr.

Issue: In the attached patch, if "right" is removed at line 16 of [codebox] in [gen~], an infinite loop occurs.

lower_bound(buf, val) {
    left = 1; // Buffer is 0-based
    right = dim(buf);
    
    while (left < right) {
        mid = int((left + right) / 2);
        
        if (peek(buf, mid) < val) {
            left = mid + 1;
        } else {
            right = mid;
        }
    }
    
    // For some reason, removing right causes an endless loop.
    return left, right;
}

Buffer buf("buf");


out1 = lower_bound(buf, 2);

causes an infinite loop. Am I missing something fundamental?

lower_bound_test.maxpat

lower_bound(buf, val) {
	left = 1; // Buffer is 0-based
	right = dim(buf);
	
	while (left < right) {
		mid = int((left + right) / 2);
		
		if (peek(buf, mid) < val) {
			left = mid + 1;
		} else {
			right = mid;
		}
	}
	
	// For some reason, removing right causes an endless loop.
	return left, right;
}

Buffer buf("buf");


out1 = lower_bound(buf, 2);

Background: I was trying to write a binary search algorithm in GenExpr.

Issue: In the attached patch, if "right" is removed at line 16 of ... 

strange-behavior-of-while-loop-in-genexpr

Update: I haven't found a solution, but whatever it is, I found the cause: removing `right` from return seems to prevent the else block from compiling. Here is an excerpt of the exported C++ source:

inline void lower_bound_buf_i(Buffer& buf, int val, int& out1, int& out2) {
    int left = ((int)1);
    int buf_dim = buf.dim;
    int buf_channels = buf.channels;
    int right = buf_dim;
    while ((left < right)) {
        // abort processing if an infinite loop is suspected;
        if (((__loopcount--) <= 0)) {
            __exception = GENLIB_ERR_LOOP_OVERFLOW;
            break ;
            
        };
        int mid = int(((left + right) * ((t_sample)0.5)));
        bool index_ignore_1 = ((mid >= buf_dim) || (mid < 0));
        // samples buf channel 1;
        t_sample peek_106 = (index_ignore_1 ? 0 : buf.read(mid, 0));
        t_sample peek_107 = mid;
        if ((peek_106 < val)) {
            left = (mid + ((int)1));
            
        } else {
            right = mid;
            
        };
        
    };
    out1 = left;
    out2 = right;
    
};

The above is the source with`right`. But, without `right`:

inline int lower_bound_buf_i(Buffer& buf, int val) {
    int left = ((int)1);
    int buf_dim = buf.dim;
    int buf_channels = buf.channels;
    int right = buf_dim;
    while ((left < right)) {
        // abort processing if an infinite loop is suspected;
        if (((__loopcount--) <= 0)) {
            __exception = GENLIB_ERR_LOOP_OVERFLOW;
            break ;
            
        };
        int mid = int(((left + right) * ((t_sample)0.5)));
        bool index_ignore_1 = ((mid >= buf_dim) || (mid < 0));
        // samples buf channel 1;
        t_sample peek_118 = (index_ignore_1 ? 0 : buf.read(mid, 0));
        t_sample peek_119 = mid;
        if ((peek_118 < val)) {
            left = (mid + ((int)1));
            
        };
    };
    return left;
    
};

Oh man, the else block is missing! Does anyone know why this happened?

same problem here: https://cycling74.com/forums/gen-ate-my-else
Why? The root cause is that gen's "optimizations" seem very ad-hoc and untested, especially with function definitions, and there is no staff assigned to work on this. You can however write to support@cycling.com with a simplified case and they will fix these bugs one-by-one.
One long-term solution would be to allow to include user-provided C code, so we could write the function code ourselves.
BTW: the code transation will be correct if you inline the function.


Cycling '74 Forums

help->examples->gen

Discord… hmmm… haha, yes: 'forums' are for old people 👵

Can you share how you are getting the sample values for the waveform? It must be during that process that something is going wrong, as...

https://cycling74.com/articles/filters-a-resource-guide-for-max-users

Buffers in gen(without the tilde) seem to be working fine on my end

Thanks, this helps! I'll try implementing it and will report back for future generations. There is a UI challenge that I have to deal with...

I needed to make an accurate latency test of my system, so I took inspiration from the old MSP latency test patch under...

This is to increase the gain by 6dB and then remove the DC offset. You want the signal to be between -1 and +1 instead of between 0 and 1.

thank you to everyone for their replies. Graham, your suggestion is pretty much exactly what I'm looking for.

same problem here: https://cycling74.com/forums/gen-ate-my-else Why? The root cause is that gen's "optimizations" seem very ad-hoc and...