Shakeeb Alireza

The GenExpr help reference provides for a case where a Param is declared inside the body of the a GenExpr function.

Yet I find that pure code Params are not recognized and give a `gen~: doesn't understand "param"`.

In my example, my two Params are not recognized unless I create corresponding [param] patch objects:

comment

button

click~

preset

flonum

message

live.gain~

ezdac~

sig~

gen~

codebox

Any help to resolve this mystery would be much appreciated.

Yet I find that pure code Params are not recognized and give a `gen~: doesn't understand "param"`. 

In my example, my two Params are not recognized unless I create corresponding  [param] patch objects:


Any  help to resolve this mystery would be much appreciated.

The GenExpr help reference provides for a case where a Param is declared inside the body of the a GenExpr function.
Yet I find that pure cod

problems-with-params-defined-inside-genexpr-functions

yes, this is the answer right now 👆(create the corresponding [param] visual-patching objects outside the codebox, then you'll be able to use them in codebox)

Params are not recognized unless I create corresponding  [param] patch objects

yes, this is the answer right now 👆(create the corresponding [param] visual-patching objects outside the codebox, then you'll be able to use them in codebox)


Thanks, Raja. Appreciate the confirmation that this is the way it works.

The GenExpr reference could be clearer about this, as I somehow got the impression after reading it that gen code in a codebox can fully substitute for gen patch code. I guess this is the exception.

Thanks, Raja. Appreciate the confirmation that this is the way it works. 

The GenExpr reference could be clearer about this, as I somehow got the impression after reading it that gen code in a codebox can fully substitute for gen patch code. I guess this is the exception.

S

I feel like it's worked both ways in the past but it's been relatively finicky. Just put the objects in.

Side note: By default, I throw all my declarations in the top right corner so they're loaded first.

I feel like it's worked both ways in the past but it's been relatively finicky.  Just put the objects in.  

Side note:  By default, I throw all my declarations in the top right corner so they're loaded first.

I had the same exact experience (it worked briefly, and then stopped working, and I couldn't get it to work again until I created the patch [param] objects).

As far as I understood, params inside functions should be viewed as attributes, not as parameters with a global scope. It is possible however to set those attributes with global parameters.

https://docs.cycling74.com/max8/vignettes/gen_genexpr#Operator_Attributes

Thanks very much for the explanation, JVKR.

So basically, there's a function scope and 'global' scope and you can link them together declaratively in the codebox or by using [param] patch objects.

I was wondering from your example whether one could use the same name for function-scope params and global-scope params and it looks like this is ok (see pasted patch.)

This has turned into a very useful thread. I get it now. Great stuff!

my bad... i've been keeping param/data/buffer separately outside codebox(then also instantiating within codebox) for a long time now... i had run into probs with it and read it somewhere on the forums here(i've also never used 'param' inside a function, the probs i ran into with param were just in global scope but declared solely within codebox... in general, i've been thinking one needs to be delicate(particularly in naming) with these ops especially: history/data/buffer/param as they're basically pointers to memory which likely require global scope). 

anyways, good to know, i'll be more scope-specific now.

my bad... i've been keeping param/data/buffer separately outside codebox(then also instantiating within codebox) for a long time now... i had run into probs with it and read it somewhere on the forums here(i've also never used 'param' inside a function, the probs i ran into with param were just in global scope but declared solely within codebox... in general, i've been thinking one needs to be delicate(particularly in naming) with these ops especially: history/data/buffer/param as they're basically pointers to memory which likely require global scope). 
anyways, good to know, i'll be more scope-specific now.

Recently I notice I'm doing as much as possible dsp in codebox only, that is certainly possible. In a way, gen~ has allowed me to see the world of dsp in a new light. It's very powerful. And not necessarily abundantly documented, but then again, the set of possible instruction is really small--in a good sense. And there are many examples now.

@ Raja, you may have encountered a bug. Could you produce an example?

@Shakeeb, the mydelay block is not just a chunk of code separated from main, but behaves truly like a function. It can be instantiated twice, as in this example. I have added a dcblock in the feedback loop.

@ Raja, you may have encountered a bug. Could you produce an example?
@Shakeeb, the mydelay block is not just a chunk of code separated from main, but behaves truly like a function. It can be instantiated twice, as in this example. I have added a dcblock in the feedback loop.

I'm drawn to gen codeblox because I just want get on with it instead of fiddling endlessly to get a patch just right.

Thanks for sharing your changes to the codeblox code. I was heading in that direction anyway with the intent of creating a delaylib.genexpr and then a reverblib.genexpr, etc.

It's interesting where you put the dcblock. In my most recent iteration (to which I have added your dual delaytime tweak) I wrapped every mix output with a dcblock and included a decay param (cribbed from the gen maxhelp) to degrade the audio over time. I have a sense the double dcblock wrap is redundant and I have no clue if I'm doing anything theoretically 'right', but so far it doesn't sound so bad.

I'm drawn to gen codeblox because I just want get on with it instead of fiddling endlessly to get a patch just right. 

Thanks for sharing your changes to the codeblox code. I was heading in that direction anyway with the intent of creating a  delaylib.genexpr and then a reverblib.genexpr, etc. 

nah, just tried, not finding it now... maybe i imagined it, or confused it with buffer(i feel i remember having a prob back in Max7 with it, though..)...

anyways, so for my clarification, one could say buffer has a 'macro' scope, while param/history/data/buffer can all have global scope, and finally, param can have both global and local scope(in codebox-relative scope)... i notice i had trouble declaring history locally in a function, too... (so i theorize: history/data/buffer can't be declared locally in functions because they are pointers to memory addresses)

hopefully i understand the ranges of scope now, though(?)

nah, just tried, not finding it now... maybe i imagined it, or confused it with buffer(i feel i remember having a prob back in Max7 with it, though..)...
anyways, so for my clarification, one could say buffer has a 'macro' scope, while param/history/data/buffer can all have global scope, and finally, param can have both global and local scope(in codebox-relative scope)... i notice i had trouble declaring history locally in a function, too... (so i theorize: history/data/buffer can't be declared locally in functions because they are pointers to memory addresses)
hopefully i understand the ranges of scope now, though(?)


Couldn't help myself. The earlier delay function I posted sounded nice but did not have the wet/dry param working properly. Here's a better version with a bunch of fixes.

Couldn't help myself. The earlier delay function  I posted sounded nice but did not have the wet/dry param working properly. Here's a better version with a bunch of fixes.

Problems with Params defined inside GenExpr functions