PlasticDSP

I can't get this to work, what's wrong with my implementation? It doesn´t sound right.

https://thewolfsound.com/allpass-based-bandstop-and-bandpass-filters/#allpass-based-bandpass-filter

CalcFreq(hz, Q)
{
	bw = hz/Q;
	omega = tan(pi*bw/samplerate);
	c = (omega-1)/(omega+1);
	d = -cos(twopi*hz/samplerate);
	return c, d;
}

History hist_a(0);
History hist_b(0);


c, d = CalcFreq(100, 3);

input = in1;

feedback = (input+((hist_a*(-d*(1-c)))+(hist_b*c)));
feedforward = (feedback*(-c))+((hist_a*(d*(1-c)))+(hist_b));

final = (-feedforward+in1)*0.5;

out1 = final;

hist_a = fixdenorm(feedback);
hist_b = fixdenorm(hist_a);

I can't get this to work, what's wrong with my implementation? It doesn´t sound right.

Resources...

gen-bandpass-filter-based-on-second-order-allpass-filter-topology

Gen~ - BandPass Filter based on Second Order Allpass Filter Topology

Emmett Palaima

Hi, I'm using gen codebox on a project for the first time, trying to figure out the syntax. 

I'm getting an error saying a variable hasn't been declared that I have clearly declared just a few lines prior. What is causing this?

Here is a screenshot of my error which states:

if (reset == 1) {
    reset = 0;
    x = 3;
    y = 3;
    xdir = 1; //xdir clearly declared here 
    ydir = 0;
    len = 1;
    step = 0;
    change = 0;

    // Initialize the array with a spiral pattern
    for (i = 0; i < 64; i += 1) {
        poke(out_list, x + (y * 8), i + 1);
        x += xdir; //says xdir is not declared

xdir is very clearly defined as a variable just a few lines prior. Why is this happening?

Data out_val(64);
Data out_list(64);

History reset(1);



amp = floor(in1 * 64);

if (reset == 1) {
    reset = 0;
    x = 3;
    y = 3;
    xdir = 1;
    ydir = 0;
    len = 1;
    step = 0;
    change = 0;

    // Initialize the array with a spiral pattern
    for (i = 0; i < 64; i += 1) {
        poke(out_list, x + (y * 8), i + 1);
        x += xdir;
        y += ydir;
        step += 1;
        if (step == len) {
            change += 1;
            if ((change % 2) == 0) {
                len += 1;
            }
            step = 0;
            if (xdir == 1) {
                xdir = 0;
                ydir = 1;
            } else if (ydir == 1) {
                xdir = -1;
                ydir = 0;
            } else if (xdir == -1) {
                xdir = 0;
                ydir = -1;
            } else if (ydir == -1) {
                xdir = 1;
                ydir = 0;
            }
        }
    }
}

for(i = 0; i < 64; i += 1){
	poke(out_val, 0, i);
}

for(i = 0; i < amp; i += 1){
	index = peek(out_list, i);
	poke(out_val, 1, index);
}


out1 = peek(out_val, 0);
out2 = peek(out_val, 1);
out3 = peek(out_val, 2);
out4 = peek(out_val, 3);
out5 = peek(out_val, 4);
out6 = peek(out_val, 5);
out7 = peek(out_val, 6);
out8 = peek(out_val, 7);
out9 = peek(out_val, 8);
out10 = peek(out_val, 9);
out11 = peek(out_val, 10);
out12 = peek(out_val, 11);
out13 = peek(out_val, 12);
out14 = peek(out_val, 13);
out15 = peek(out_val, 14);
out16 = peek(out_val, 15);
out17 = peek(out_val, 16);
out18 = peek(out_val, 17);
out19 = peek(out_val, 18);
out20 = peek(out_val, 19);
out21 = peek(out_val, 20);
out22 = peek(out_val, 21);
out23 = peek(out_val, 22);
out24 = peek(out_val, 23);
out25 = peek(out_val, 24);
out26 = peek(out_val, 25);
out27 = peek(out_val, 26);
out28 = peek(out_val, 27);
out29 = peek(out_val, 28);
out30 = peek(out_val, 29);
out31 = peek(out_val, 30);
out32 = peek(out_val, 31);
out33 = peek(out_val, 32);
out34 = peek(out_val, 33);
out35 = peek(out_val, 34);
out36 = peek(out_val, 35);
out37 = peek(out_val, 36);
out38 = peek(out_val, 37);
out39 = peek(out_val, 38);
out40 = peek(out_val, 39);
out41 = peek(out_val, 40);
out42 = peek(out_val, 41);
out43 = peek(out_val, 42);
out44 = peek(out_val, 43);
out45 = peek(out_val, 44);
out46 = peek(out_val, 45);
out47 = peek(out_val, 46);
out48 = peek(out_val, 47);
out49 = peek(out_val, 48);
out50 = peek(out_val, 49);
out51 = peek(out_val, 50);
out52 = peek(out_val, 51);
out53 = peek(out_val, 52);
out54 = peek(out_val, 53);
out55 = peek(out_val, 54);
out56 = peek(out_val, 55);
out57 = peek(out_val, 56);
out58 = peek(out_val, 57);
out59 = peek(out_val, 58);
out60 = peek(out_val, 59);
out61 = peek(out_val, 60);
out62 = peek(out_val, 61);
out63 = peek(out_val, 62);
out64 = peek(out_val, 63);

variable-not-defined-error-gen-codebox

Variable Not Defined Error Gen Codebox

axers fall

In this video,I will show you how to make a 

 environment only with this magical process.

Please check out my youtube channel for more Max/MSP ambient sound design videos!!!

https://youtube.com/@axersfall369?si=jcT1WG6KZFKHOkqd

In this video,I will show you how to make a fast fade-in amplitude envelope,simple one-pole lowpass filter and pitch glide effect in gen~...

maxmsp-this-magical-process-in-gen

[Max/MSP] This magical process in gen~

Leonard Zajdek

Hi - i am relatively new to Max8 / MSP / gen~ and generally its coming along fine but there is this thing bugging me - itsa question concerning the [ scale 1 0 0 1 -1 ] operator within the abstraction go.unit.trapezoid.gendsp

on page 68 of the amazing book "Generating Sound & Organizing Time" -

by what calculation does the fifth argument (-1) in [scale 1 0 0 1 -1 ] accomplish its task here?

i understand the function of the [scale] operator - and i am familiar with the maths and graphs of exponential curves - it is just i cannot grasp how this (-1)  affects the offset [phasor] slope the way it does when it enters the following [ * ] operator .

will be grateful for a kind explanation -

Hi - i am relatively new to Max8 / MSP / gen~ and generally its coming along fine but there is this thing bugging me - itsa question...

how-does-1-function-as-a-fifth-argument-in-the-scale-operator

how does ( -1 ) function as a fifth argument in the [scale] operator?

Luca Schwarz

Hi there! I love the function you can get the name of the in/out objects in (gen)patchers in a parent patcher when hovering the mouse over a specific input/output. Makes live much more easier. Somehow i realsied that gen will not display these names reliable. Pretty sure i am missing out on some infomartion, but any help would be deeply apreciated.

Input / Output information of gen patchers disapear / appear

input-output-information-of-gen-patchers-disapear-appear

Justin Daley

Hello wizards. I’m putting together a looper in Gen~ for use on a Daisy seed. I’ve got it set up to poke a data object while holding down a switch (sw5), and stop things with the next press of the switch. Mix is on knob 1, and knob 2 cycles some wacky playback options. It’s probably pretty clumsy, I’m new to Max and gen~ so I’m sure it can be improved on many levels…

What I’m especially having trouble with though is understanding how to make this into more of a ‘pedal style’ looper control. Meaning, I’d love to be able to press the switch once for start/record, press again to stop recording/play loop, press again to overdub, and long press to clear/stop. I’ve found some useful threads on ‘button logics’ by G. Wakefield, but can’t seem to wrap my head around implementing them. I’ve read the forum back as far as it goes (which was super helpful), but I’m still having a tough time with it… any help or critique you’d be willing to share?

Daisy Looper.maxpat

Hello wizards. I’m putting together a looper in Gen~ for use on a Daisy seed. I’ve got it set up to poke a data object while holding down a 

gen~-looper-logicoverdub-question

Hi, 
i'm a bit foggy on the details(been so long ago, and it didn't seem to add much to what was already out there, so i decided to try and learn C++ more for electrosmith daisy stuff), but here's my 'snippet-looper' from long ago in case it helps:

but it might be too much to digest all at once, so to answer your questions more specifically:

I’d love to be able to press the switch once for start/record, press again to stop recording/play loop, press again to overdub

it looks like you've already done something like this(not finding much time to look in detail), but basically, you can use an accumulator(+=) to detect the switch presses, and count each one upwards, then route each number to an action, which can be done using a 'gate' op... or, you can do it in a more basic/explicit-style like so:

(i used '< 0' after 'delta' to detect based on lifting 'off' the switch, but you can change the '<' to '>' if you prefer detecting based from 'on' presses)

however, i might split your tasks apart so that the third part('overdub') is conditional based on whether the buffer was cleared or not:

press again to overdub, and long press to clear/stop

i'm unable to come up with a quick/easy patch example for that, but basically, store a value that would indicate the buffer was cleared(was hinting at this in the above pic, referring to 'reset action' but there may be better ways to set that whole situation up), and then if the buffer was cleared, instead of overdubbing, just go straight to record, otherwise, you could also just stop the loop temporarily(?)... this is just an idea... 

[EDIT: actually, my bad, that looks wrong, you would want an additional reset going into the '+=' op near the top-right of the above pic, that would restart the sample-rate count each time the switch is pressed(or lifted off from)... but hopefully you get the ideas]

that's from my 'Snoopsy' patch uploaded above, but i use it differently there, you would want to create that within a longer 'codebox', where you can setup that same code, but have the 'true'(1) condition trigger a 'for' loop that writes '0' to every sample of your 'data' op(this is how you can clear buffer/data ops instantly(within the timing of one-sample... depending on how cpu-intensive everything else is, if too intensive, can be a bit glitchy... but your patch doesn't look too intensive so far :))... keeping in mind, to stop playback beforehand, otherwise, you'll get clicks(you probably indicated this already in your description, "long press to clear/stop", but just making sure to state the proper progression outright).

if you get really great at codebox, much or all of this can be concisely written into that, too. 
sometimes you might try starting threads here within the gen~ subforum, where instead of asking about 'Oopsy' specifically, you can try/demo smaller bits of your patch within gen~ by itself, piece-by-piece, and you might get quicker answers, too.

hope this helps until someone else further-in-the-know can give you better answers 🍻

Thanks a million for the ideas, and also the suggestion to not necessarily call out Oopsy and test out smaller bits of the patch! I’d love to get better with codebox, hopefully soon… 

Thanks for sharing the Snoopsy (also my wife’s name) I’ll dissect and learn what I can from that too! You’re the best!

Can I ask for one small clarification please? This concept of a 

'codebox', where you can setup that same code, but have the 'true'(1) condition trigger a 'for' loop that writes '0' to every sample of your 'data' op(this is how you can clear buffer/data ops instantly

Will this need to happen into the inlet of a poke object? That’s the only way input into a data object, correct?

poke ops can be coded within codebox as within a gen~ patcher as visual versions...
if i recall correctly, everything in the visual object form within gen~ can actually be translated to an 'op' within codebox, including your 'data loop1' object.

a simple codebox to clear your 'data loop1' buffer would be this, but keep in mind, since i'm declaring the 'loop1' data/buffer within codebox here, you might want to delete the visual object version from the main gen~ patcher, and only have it within the codebox:Data loop1(768000);
if(in1>0)
{
	for(i = 0; i < dim(loop1); i += 1)
	{
		poke(loop1, i, 0);
	}
}
(i can't remember since i've not worked with these details in awhile but it's best to only have buffer/data/history ops declared once within a gen~ patcher, otherwise, since it's referring to a physical hardware memory-space, it might get confused, or rename things internally to create separate data spaces... other ops like 'poke' and 'peek' can have multiple copies of the same name, so long as you remember where everything is and delineate what they're doing separate from each other, should be fine...

many things like History, Data, Buffer, etc. will need to be capitalized in codebox, as this is more like a declaration of an instance from a class within code as with many other programming languages, whereas the visual version of ops in gen~ will be left lower case as that's in keeping with the visual-object style of Max proper)

we can test this out further by using buffer instead(just for a Max-patcher-only demonstration), and by having a buffer refer to a buffer~ in the outer max patch, will allow you to double-click on buffer/buffer~(you can double-click on the gen~ op, or on the outer max object to see[edit: oh but i use the buffer op in codebox, so i guess you can't double-click on this one within gen~ below, have to use the outer max-patch buffer~... i commented as such in the patch to make it clear :)]), and check it's empty after writing something in it, here i've created a quick patch that can help you understand just that:

{Edit: that test patch pasted above is not an efficient one at all, while leaving the toggle on, it's constantly writing the entire buffer~ with 0s, basically cycling through 256 samples at a time, clearing them to 0, within the timing of one-sample at sample-rate... but in your oopsy patch, you'll have a different triggering mechanism that hopefully only triggers it once(during one single sample, not constantly) whenever you need it... like [Param sw1] -> [delta] -> [< 0] -> [codebox]}


and finally, while the docs are extensive and can help a great deal, much of this i learned by clicking the 'C' icon in the right-hand toolbar, and looking at the code posted there after creating visual versions of what i wanted first, here's a pic that shows what i mean where i just highlight the one 'poke' object in your patch i wanted to research within the code(to remember what all the inputs are), and you'll see it highlights the equivalent line of code:

for your patch, i don't recommend just copying and pasting all that code shown within the 'C' icon's display into one codebox(gen~ will rename things with its own naming scheme that's very confusing for human-readability, and there's often redundant lines you don't need to write as much into codebox, even if it will translate into something more verbose for itself after you create something in codebox... and also, as it does this, it doesn't necessarily mean when it finally runs or exports to C++, that it will be less efficient(this is just the way it translates at first, then under-the-hood, will streamline for you)).
hope that all makes sense and helps 🍻

Thanks for sharing the Snoopsy (also my wife’s name) I’ll ... learn what I can...

cool name! (yes, one's wife is always the best to learn from, about all things in life) 😄

I have been trying t0 implement something similar in the example chopper patch to run on a Mod Dwarf

I have it working in Max okay, the chopper patch uses multiple channels so I made a nested for loop to read the channels and write zero to each data object.

However, I am getting some CPU spikes when I load it into the Dwarf. This is causing a very audible glitch when the clear Param is triggered. 

I realise that there may not be many on the forum here that have any experience with the Dwarf but if someone could take a look at this code, check it's done right, I would be very grateful. I am not entirely certain I have implemented the 'delta' object properly in the codebox.

The for loop is on line 141 of the code box.

There's a lot going on with these patches so I'm going to try and offer a few more general thoughts that might be useful. 


Clearing the contents of a buffer or data means writing zeroes to every sample frame. In the OP's patch for example that means 768000 samples at once. Trying to do this all at once in a for loop will definitely cause a CPU spike (and on embedded hardware sometimes that can cause a lock up).  It's best to avoid doing this!

The best option is to design the algorithm so that clearing the data isn't necessary. For a simple looper example, you can have some flag that marks where the loop start & end points are, and to clear the data, you can just set them to the same value (meaning, there's no data between start & end). Your playback algorithm then simply plays nothing until the loop is marked valid by having different start & end points.  The old audio is still there in the data, but is unreachable because it's outside the loop points.  (Actually this is roughly also how a lot of garbage collection algorithms work -- the memory isn't zeroed, it's just marked as unreachable/re-usable.)  So, for example in the OP's patch, the "long press" could simply set both loop points to zero. No data clearing needed! 


The next best option is to use a lazy algorithm. That means, don't try to erase all the data now, erase each sample only when you absolutely need to. There are many  variants of this model. Make sure to learn how the 4th inlet of poke works -- it can make overdubbing/mixing applications super easy.


A related option works a bit like a tape loop: you have a read head that is continuously stepping through the tape one sample at a time (e.g. a [peek] driven by a [counter]), and right after you read it, you erase it ("burn after reading").  You can ensure the order of operation here without needing a codebox: the last output of the [peek] is the sample index that you feed into the [poke] that erases the tape.  In this model you can have other writer heads writing data "into the future" in the tape, by adding some offset to the current read head position. 

In the worst case that you really do need the data to be quickly zeroed, the best thing to do is to spread this out over a short duration rather than all at once, such as zeroing 32 samples for each passing sample frame, so that there's no CPU spike. So, if your data represented one second of audio, it would take 1/32 of a second to clear it -- it takes you longer to push and release a button with your foot.  The output of the codebox tells you if it is currently erasing.That can  be done using a codebox for loop. Let's say you have a [history erase] and a [data loopdata 768000] and you trigger an erase event by setting erase = 0, then your codebox can be something like:

Data loopdata(768000);
History erase;
if (erase < dim(loopdata)) {
    end = erase + 32;
    while (erase < end) {
        poke(loopdata, 0, erase);
        erase += 1;
    }
}
out1 = erase < dim(loopdata);

BTW one other tip: if you are handling button presses on embedded hardware, you probably need to "debounce" the button using a schmidtt trigger: that means using different thresholds to turn on and to turn off. Otherwise, you might get a lot of false on/off triggers due to noisy circuits when the value is really close to the threshold.  E.g., if you wanted a threshold of about 0.5, maybe make the on threshold be 0.6 and the off threshold be 0.4. To turn on you have to go above 0.6, and then to turn off again you have to go below 0.4.  You can do this with a [switch 0.4 0.6] routed into the right inlet of a [< ] operator, and feed the output of that through a [history] back into the [switch 0.4 0.6].  :-)

I’ve got a long way to go yet in gen~, but I really appreciate your patient guidance! I’m starting at the beginning of the new book today, and hopefully will absorb what I need to think in gen~!

Here's a somewhat simplified version of a looper. 

The core idea here is that we are continuously reading & writing to the data. What we read is delayed relative to the write position according to the current loop length. So, this is a kind of delay effect really. While erasing, the delayed signal is zeroed. While recording, the raw input is added to what is written. Setting a new loop means erasing and recording at the same time; overdubbing means recording only. 
Another section of the patch deals with setting the loop length. At the moment the erase button is pressed (rising edge), it sets the loop len to zero. At the moment the record button is enabled -- but only if the loop len is currently zero -- it starts a sample timer [+= 1]. At the moment the record button is released -- but only if the loop len is currently zero -- then it sets the loop len to the sample timer. Otherwise the loop len remains unchanged. 

That's enough to effectively get the ability to create new loops, and selectively overdub. You could embellish this in many ways -- a few samples' of crossfade for the read/write [mix] ops would be a good idea to suppress clicks. Some other schema for controlling rec/overdub/erase could be explored. Etc.

Hope this helps!

Here's a bare bones looper to compare with. The core idea is closer to what a delay line is: we're continuously writing to a data, with a mixture of the raw input and the delayed data (according to the loop length, and the parameters of whether to erase and/or record). 

Another section of the patch handles the logic to set a new loop length, which happens when both record & erase are enabled at the same time. 

Thanks @Graham Wakefield for the super detailed feedback. I think I understand how I can implement some of the things you are suggesting but my programming skills are more hack away at the code until it does what I want rather that actually knowing what I'm doing!

Atm, I have the chopper set up on the Dwarf in such a way that a switch routes a noise generator with volume down to the input of the chopper, this effectively writes 'silence' to the segment_data data object. This works after a fashion but I am looking forward to trying your suggestions.

Trying to do this all at once in a for loop will definitely cause a CPU spike (and on embedded hardware sometimes that can cause a lock up).  It's best to avoid doing this!

Oops, my bad, i didn’t know this, especially that about embedded hardware - extra great to know now
Thank You Immensely (i’ve become too spoiled/ignorant from being able to brute-force samps en-masse with buffer~ in Max on a laptop for years haha… and the ideas about clearing in blocks, or setting a flag to check if start==end is so helpful too), Very grateful!

Gen~ Oopsy Looper Logic/Overdub Question

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? 

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...

Cycling '74 Forums

I can't get this to work, what's wrong with my implementation? It doesn´t sound right. Resources...

Variable Not Defined Error Gen Codebox

In this video,I will show you how to make a fast fade-in amplitude envelope,simple one-pole lowpass filter and pitch glide effect in gen~...

Thanks for that Graham - and for the longer explanation - they're the kind i like - i'm at peace now - - i had been sticking all kinds of...

ok figured out that they will be only displayed if they are connected to another object, i guess this is solved =D

But I think I should restate what I said in the post above -- "The best option is to design the algorithm so that clearing the data isn't...

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