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

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?

Strange behavior of while loop in GenExpr

Tarik Barri

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?

soundyi

Hi there,
I stumbled upon this weirdness of code generation issue, where an essential else block is dropped … most probably as the value set inside the else block is not directly part of the jit.gen codebox outputs.

If you run the attached patcher it works as expected, as I added a workaround via a variable called dummy.

If you open the jit.gen patch and also the „code“ sidebar, watch what happens if you comment out line 41 with the else block surrounding it : it disappears aka its optimised away.

And executing the patch leads to wrong results - as the logic depends on the boolean flag reset in this else block.

It took me quite a long time, to encircle the cause … and by the way I also stumbled upon the issue that assigning 1-plane vectors to the outputs via „out1 = vec(42)“ leads to a non interpretable compiler error and has to be done in a scalar fashion „out1 = 42“ … weird too, especially as this error is not hinted in the codebox, but only if one executes the parent patcher.

I can image some „code work“ to substitute the dropped boolean logic … but why shall I ???

To some extent its recognisable that the else block gets optimised away, as there is only 1 variable changed inside and this does not directly contribute to the output … BUT if this kind of thinking really rules, we end up in a assembler programming style … and if I am forced to develop software (and especially pieces of art, which should be a joy !) in this mind boggling kind of thinking, I am better off beaming myself back into stone age ;-).

Why do you drop into the darkness of codebox in the first place, you may ask? Stay in the joyful field of operators patching in a „normal“ jit.gen patcher and everything is fine, you may argue ;-).

Yes, I really would like to do so … but I need the sweet sugar of „loops“.

As an example : scanning matrices (or textures with jit.gl.pix) in rows or lines, or the surrounding area of a pixel is very easy to do with a for loop.

So patching generative art in the style of „nature of code“ (flow fields, boids flocking and alike), its a great option to have the codebox and its for & while loop features.

JitGen Code Generation Optimization Issue.maxpat

Hi there,
I stumbled upon this weirdness of code generation issue, where an essential else block is dropped … most probably as the value ... 

codebox-in-jitgen-code-generation-issue-essential-code-gets-optimised-away

Codebox in Jit.Gen : code generation issue - essential code gets optimised away

Fábio Santos

I think I found something strange in the last patch from the second chapter an I’d like to discuss it to see if it is only me..

In the 3th outlet from gen (merged shapes), if I mess with the “shape” and "skew" params, it falls out of 0 - 1 range by very high values witch is strange because it gets out of a go.ramp_div with a wrap 0. 1.

Can anyone explain to me why and how to solve it?

Hello.
I think I found something strange in the last patch from the second chapter an I’d like to discuss it to see if it is only ... 

generating-sound-organizing-time-issue-in-chapter-2-last-patch

Hey Fabio 👋 🙌
can't seem to reproduce here, stays wrapped between 0 and 1 for me(?)
maybe you can take a screenshot of the exact parameter settings for the whole patch when you run into this problem, and folks can try those exact settings to repro?


My sentiments precisely. Unless we have a bit more information, it's going to be difficult to guess what the problem might be if our attempts to reproduce the report don't have the same result. Fabio, can you help us?

Hi, here's a video where I slowly start by changing the "shape2" parameter.

oh damn, ya, looks like it goes way off in the vid... i still can't reproduce here though...you could try grabbing a fresh copy of the patches and try again just in case there's something unexpectedly changed/unique about your copies, but since i can't seem to repro, i'll let others test and chime in from here.

I asked on Facebook and Discord and there were more people with the patch having the same behavior..

Oh, I just got this behavior! I decided to try this out on my Windows10 PC.
hadn't used it in awhile, Max was still at 8.1.11... i downloaded the GO patches, tried that patch out, i got the problem slowly scrolling closer back to 1. on the 'shape2' parameter after scrolling it all the way to 0., then decided to update my version of Max to the current version 8.5.1, tried the same exact steps above, and i get the same problem(...perhaps it's specific to Windows because i don't have this problem on my Mac(?))

anyways, just sharing the new info. here(may be good to start gathering people's system specs who run into this prob(both max version and OS), then with a few cases, send it on to support, unless you've already heard from em).

I'm a bit ashamed, but where the hell can you download the patches ? I've bought the book, but I couldn't find the patches, or anything related to how to download them in the book. 
What did I miss ? 

The link is in Chapter 1(in my paperback edition it's on page 3)... it's sort of a short url, easy to miss(but near the end of the section titled, "Using this book(and the software that comes with it)").

Thank you ! 
I totally missed it, and have been looking for it without luck. 
It could be stated more clearly in my opinion. 

This book will be my christmas present to myself. I love working in gen~, but for some time now I've been very "patch of least resistance", so I'll build it in reg. max, since I'm faster there.

Here's my system specs.
Max is updated and my audio Driver in Max is a Motu mk 5.

It's funny, if I update the [out 3] object, the ranges came back to 0. 1..

Edit:
I’m not on my computer now but it’s probably because it updates the [gen~] object.

Given the time passed with no solutions, I’ll ask for Cycling’s suporte.
I‘ll report here any useful update.

sounds good, Fabio. (if you didn't already, i'd suggest maybe waiting til Tuesday, as this weekend is Thanksgiving in the US, maybe folks will see this more starting Monday(?)... but no worries overall, this seems like it's definitely unexpected/undesirable behavior)

here's my system specs(since it's audio-specific i just gave this much but if you need more let me know) - was running 'ad_mme' for the driver, no special I/O just 'speakers/headphones(realtek(r))':


...and (although i first saw it with my Max out-of-date at version 8.1.11), i also see this issue in the current version for max on my windows machine: Max8.5.1 ..i still don't find this issue at all on my Mac, which is also running the current version of Max, and is at MacOS12.4(Monterey - running just CoreAudio(built-in through speakers) for the driver)

Thanks a lot, I’ll wait till Tuesday.
I hope they can fix it, it’s such a cool feature.

I've bought the book, but I couldn't download the patches. The provided URL doesn't work anymore.

@Christoph Maurer
I've confirmed that the download URL works for me and others - I'd recommend getting in touch with Cycling '74 Support to get that sorted for you.

The URL is working here too. Perhaps try with a different browser, or refresh the browser cache, make sure the browser security isn't preventing downloads etc.? 

We are looking into the problem with the final patch in chapter 2 on Windows. As noted above, the [wrap 0 1] at the end of the [go.ramp.div] should be preventing these kinds of runaway values from happening. 

I can confirm that that there is a bug here. Briefly, on Windows, a [wrap] output can sometimes behave badly when the input value is extremely large.  The example patcher in the gen~ book, under certain modulations, can cause this to happen.  I hope we can get a fix for this into gen~ very soon. 

Hello everybody.
Is there any news in this matter??

Generating Sound & Organizing Time issue in chapter 2 last patch.

luvulongtime

When using a 3-plane 1d-matrix in Jit.gen it will assign dim().x to y and z as well. If you use a 3-plane 2d-matrix Gen will output a 0 for the z value. 

Came across this when summing all the values of a matrix in Gen and calculating the mean. I noticed the mean still appearing correct but the sum was off. 

So you need to let Gen know beforehand how many dimensions a matrix has and accommodate for this. I actually expected dim().y to be 1 when using a 1d matrix because having it like this would keep any nested for-loops working right? The code in this example would break if it had a for-loop for a 3d matrix and would be given a 2d matrix.

Hello,
When using a 3-plane 1d-matrix in Jit.gen it will assign dim().x to y and z as well. 

idiosyncrasy-of-dim-in-gen-when-using-a-1d2d-matrix

Idiosyncrasy of dim() in Gen when using a 1d/2d matrix

Ian Dicke

I'm worried this is a stupid question, but why does the buffer inside of Gen report a different length compared with the info~ object outside of it? I'm looking at the length in samples (not ms). 

I'm worried this is a stupid question, but why does the buffer inside of Gen report a different length compared with the info~ object ... 

gen~-buffer-reports-different-length-vs-regular-buffer~

can be mismatch of sample rate
load sample which has same rate as set in max.
stil wrong ?


Hey Ian,
you might wanna have a look at the "info~" helpfile there you will find the solution.

Thanks @Steven Kuhlmann, that clears it up!

Gen~ Buffer Reports Different Length Vs. Info~

gnilcyc

I am currently studying gen~ and I'm facing an error that is difficult for me to understand. To provide a better explanation, I have recorded a video showing the error. It's a short video, so please take a look.

https://drive.google.com/file/d/1lc32RH6YFv-1dY5SOiMCbHlqqJyMP5Jn/view?usp=sharing 

When I connect it to [out 5], no data is being outputted, but when I create a new [out 7] and connect it, data is being outputted. Similarly, when I connect the code from [* 60], no data is being outputted, but when I connect it from [out 5] instead, data is being outputted. What could be the problem? Also, when data is not being outputted, the color of the [out 5] inlet is not red.

I'm not sure if the same error will occur on other computers, but I'm also uploading the patch along with it.

16_ramp_to_freq.maxpat

I am currently studying gen~ and I'm facing an error that is difficult for me to understand. 

i-seem-to-be-encountering-an-error-when-connecting-code-to-inlets-in-gen~

i'm unable to confirm the behavior with your same exact patch(i think that's because it's already created with everything in place, and so the dsp will compile properly from start)... but going by the video, it looks like you're able to return it to normal function eventually, this implies some problem with compilation upon initial creation of objects, so if you run into quirky behavior like this you could try restarting the audio engine, or possibly manually compiling(see the bottom toolbar within gen~, you can disable auto-compile then re-enable to force compile, or disable, then use the regular 'compile' button next to it(in which case you'll need to do that with every change you make thereafter until you re-enable auto-compile again))... but for every problem like this that i've run into(MC objects have had issues that could be solved like this, too), turning the DSP off and then back on again usually is enough to fix it(try that first).

if you keep running into this strange behavior and can isolate the problem into reproducible steps, you can submit a ticket about it here:
https://cycling74.com/support/contact 

I seem to be encountering an error when connecting code to Inlets in gen~.

Diemo Schwarz

I'm doing some image analysis in (message-based) gen, on an unrolled matrix copied into a jit.buffer~.  (This is the only practical way I found to implement a weighted histogram.) However, already with small test images of 640 x 480, this makes for > 300000 iterations, which is larger than the security limit GENLIB_LOOPCOUNT_BAIL = 100000, and gen stops working with warning:

gen: audio processing exception: Too many iterations (runaway loop?)

How can I augment or remove this unpractical and rather artificial limit?

I'm doing some image analysis in (message-based) gen, on an unrolled matrix copied into a jit.buffer~. 

augment-gen-loopcount-limit-for-image-analysis

I don't know if this limit can be removed or edited, but a possible workaround could be to split the iteration over multiple calls. I mean something like this:

You would have, of course, to keep track of the variables and plug them back into gen, but if you can do something similar, it should work.

EDIT:
this is a version of the patch above with a selectable number of iterations.

augment gen loopcount limit for image analysis

but no indication what the problem is. What's more, the code compiles either by commenting the line

or by uncommenting the block in /* ... */ (which does the same calculation as the warmness function).
This hints at a translation problem in gen.
Any insights are welcome.
Best

warmness (h, s, v)
{
	T = 0;
	w = s * v; //weighted 
	h = h*360; //hue on a 360° circle
	if (h > 75 && h < 285) //binary assignement
	{
		T = -1;
	}
	else
	{
		T = 1;
	}
 
	thet = T * w;
	return thet; 
}

index = swiz(cell, 0); // histogram bin index
hue = floor(index / 64);
sat = floor((index - hue * 64) / 8);
val = index - hue * 64 - sat * 8;

// this line makes gen not compile...
theta = warmness(hue, sat, val);

/*...but only when this block is commented....
// if uncommented, it compiles!
	T = 0;
	w = sat * val / 64; //weighted with s * v in [0..1]
	hue = hue / 32 * 360; //hue on a 360° circle
	if (hue > 75 && hue < 285) //binary assignement
	{
		T = -1;
	}
	else
	{
		T = 1;
	}
 
	theta = T * w;
*/
out1 = theta;

another gen conundrum: below code gives 
jit_gen: Gen patcher not compiled
but no indication what the problem is. 

another-day-another-unexplainable-gen-compilation-error

ha, i've broken gen many times using reserved words(kept naming my params 'mix' whenever it controlled the mix of the 'mix' object,  😅 ...for some reason, it would work sometimes, and then as the patch grew more complex, not)

it is definitely not a reserved word problem (same error with a different name).
However, further testing reveals a hint that it is a problem with the function after all:
Simply having a line assigning to theta will make the code compile, e.g.

thetaxxx = warmness(hue, sat, val);
thetaxxx = 0;
out1 = thetaxxx;

presumably this is because the translator figures out that the function's return value is not used and the call can be elided.
So, gen has a problem with the function mechanism itself, because the same code inline works fine.


After more trials and simplifications, I could pinpoint gen's translation error:

func3 (h, s, v)
{
  h = 1; // assigning to a function param is an undocumented and undetected gen error
  return s * h; 
}
res = func3(1, 2, 3); // only when the function is called, does gen report that it can't compile
out1 = res;
The question for us all is: Why should we put up with this? Why should we lose an hour of creative work, figuring out by ourselves some limitation of the gen language that shouldn't be there in the first place, but that should at least be documented somewhere, and that MUST be detected and reported as an error by the translator.

The question for us all is: Why should we put up with this?

my humble condolences for your trouble here, and utmost gratitude for finding this... and i pretty much agree with your sentiment(there's alot to be desired in the way the entire Max environ is being documented these days: you have to go on Discord(and there too, you'll have better luck if you go at certain times), you have to learn how to get around the search on this site(by not using it at all), you have to find this or that YouTube channel for some esoteric information(and if you're looking for something specific, it can be difficult to use someone's channel page to search there), and to be honest with you: i don't exactly put up with it - for example, i've gotten so used to struggling on my own with Max, that i never file bug-reports anymore - if they want us to struggle so hard to learn their environ, they should struggle harder and harder to keep it afloat on their own... we shouldn't do any extra work unless they pay us at this point).
this is a problem with many of the 'tech communities' these days: without proper documentation, it becomes elitist, because the 'cool people' who are connected with the devs or the ones who create the newer functionalities, will get this information first, while the rest of us have to yell on forums because we don't even know what we're missing yet(and this might be more acceptable in a fully open-source context, but not at all when we pay for a product).

[Edit: also, Rob Ramirez has probably been the most helpful and sharing of all at Cycling74, they should give him a serious raise and model the rest of their participation and care after him <3]


One thing that could make gen less unexpected and more efficient would be to allow to declare and call C functions in a codebox.  Then one could do proper integer arithmetic, too. 

And thanks for your compassion, Raja, it warms my heart.  I agree, Rob and Joshua have been stellar in helping to figure out all these little and big undocumented quirks in gen.  It would be easier on them, too, to finalise genexpr with a properly defined, documented, and validated syntax and semantics.


another day, another unexplainable gen compilation error

this code shows that Data can not be resized by changing a Param.  Is there a way to somehow pass in the param's default value from the containing patch? (Something like "gen @number 8", which doesn't work...)
It also shows a translation error, allowing to overwrite the param from a function (but not to read it).
Cheers...  Diemo

func(a)
{
	//ret = number; // <-- this read of the Param gives an (indescriptive) error
	number = 99; // this overwrites the Param!!!
	ret = peek(a, 0, number); // ...but only if it is used here
	return ret;
}
Param number;
Data arr(8, number); // changing the Param does not resize the Data arr

func(arr);
poke(arr, 99, in1, in2);
out1 = peek(arr, in1, in2);
out2 = number;

gen param test.maxpat

this code shows that Data can not be resized by changing a Param. 

variable-size-data-arrays-and-a-translation-error

Sorry - you cannot change the size of a data operator on the fly.

You'll need to keep track of the size of your data operator's contents and adjust the ways that you interact with the changing size of your data operator accordingly (things like peeks/samples and pokes, counting your way through the data operator's contents, etc.).



Hi Diemo! 

Yes exactly as Gregory says, unfortunately a [data] cannot be resized dynamically; the arguments to the Data object constructor must be constants.  

(For the technical reason why: we determined very early on in gen~ development to disallow dynamic memory allocation within the code generated by gen~, since a) memory allocation by default is an operating system call that can cause unpredictable delays on different kinds of CPUs, and can be problematic on embedded devices too, which could cause audio dropouts, b) writing a fast dynamic-safe allocator is possible in certain conditions but may require re-implementation for different export targets, and c) letting a generative algorithm or simply a typo error in code suddenly cause huge unintended allocations, possibly at sample rates or faster, would be a disastrous thing to unleash, etc.) 

As Gregory says, the best policy is to pre-allocate as much memory as you anticipate needing in the [data] object, and then use your [param number] or something similar to identify how much of this data you will actually be using at any particular moment. 

One other comment from your code above -- hope it helps clarify a bit more:

You can't refer to a global Param or Data etc. within a function, unless you pass that param value or data reference into the function as an argument. Functions are more like patcher abstractions, best to think of them as a self-contained chunk of code that you can put inputs into and get outputs out of.  They don't have scope access to variables, param, data, history etc. from your main body of code. So the first line in the function (`ret = number;`) is really an error of referring to a variable that is not within the scope in the function, or hasn't (yet) been declared within the function. The next line in the function (`number = 99;`) doesn't overwrite the param (because params are not visible within functions), it just creates a new local variable called "number". This new variable is local to the function and will disappear when the function returns.  

I realize you might have been asking a different question, which is "how can a gen subpatcher initialize data to a length computed according to some constant thing in the parent gen~ patcher", and I'm afraid that it is a good question and I don't think there is a solution at the moment. 

You *can* do some constant expression computations in data arguments, e.g. [data 16*16] or [data samplerate/2] etc., but this constant expression parser in gen~ can't read things from outside of that context, and can't refer to a [param] or an input from a parent patcher, as these are not evaluated as constants in the type system evaluator. 

Dear Greg and Graham, thanks for your insights on these gritty gen details!

I realize you might have been asking a different question, which is "how can a gen subpatcher initialize data to a length computed according to some constant thing in the parent gen~ patcher", and I'm afraid that it is a good question and I don't think there is a solution at the moment.

This was the exact question I was asking, can the Data's size be determined from the containing patch, like #1 can be used in an abstraction. One pbly could use scripting?
OTOH, one can see in the compiled code that memory allocation happens in the generated reset() method, so technically, the allocated size could be different at each call of reset().

You can't refer to a global Param or Data etc. within a function, unless you pass that param value or data reference into the function as an argument. 

That's what Joshua found out and told me, too. I would have loved to read that information somewhere, especially after running around in circles in the gen documentation for hours.

 So the first line in the function (`ret = number;`) is really an error of referring to a variable that is not within the scope in the function.

Yes, the code doesn't compile, but the error doesn't give the slightest hint what's wrong:
gen_domain: dsp.gen: [string "-- main2.lua..."]:697: failed to compile genpatcher

The next line in the function (`number = 99;`) doesn't overwrite the param (because params are not visible within functions), it just creates a new local variable called "number".

Except that it DOES overwrite the param. No local variable is created:

inline t_sample func_dat(Data& a) {
		m_number_1 = int(((int)99));
                ... }


If you're asking about the upper limit number at which things terminate, it's um... 100,000. I'm sure that Graham will correct me if I'm wrong.

But interpreting that value is not as straight ahead as you might imagine, since it concerns every iteration for all for or while loops you've got in your codebox operator. And there's an additional thing to keep in mind, too -  The count resets at the start of a sample block, which means that a larger block size is going to mean more loop counts. So the answer on that high number is, "It depends."

@Gregory, was your answer above maybe intended for the other active gen thread here?

Cycling '74 Forums

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

Yes actually I noticed this too and this can help indeed. Not with the other errors unfortunately.

Hi there, I stumbled upon this weirdness of code generation issue, where an essential else block is dropped … most probably as the value ...

Hello everybody. Is there any news in this matter??

Hello, When using a 3-plane 1d-matrix in Jit.gen it will assign dim().x to y and z as well.

Thanks @Steven Kuhlmann, that clears it up!

i'm unable to confirm the behavior with your same exact patch(i think that's because it's already created with everything in place, and so ...

Hi Diemo, I don't know if this limit can be removed or edited, but a possible workaround could be to split the iteration over multiple ...

One thing that could make gen less unexpected and more efficient would be to allow to declare and call C functions in a codebox.

Dear Greg and Graham, thanks for your insights on these gritty gen details! I realize you might have been asking a different question, ...