gen~ : 'blocks' to auto-generated genexpr code issue ..??

Any hint please? Downloaded MAX version 7.2.2. But the bug still here.

Additionally I did this :

1- I disconnected one plug and suddenly reconnected it to its previous position.

2- Then I copied the auto-generated genexpr code, pasted into a Codebox, linked the output and...

And this time that specific param worked correctly !

But if I do the same for any other param, then (after copy-paste the auto-generated genexpr code , bla bla bla...), the previous param (I disconnected-reconnected previously) again stop working correctly.

Maybe an issue/malfunctioning in the way gen~ names/renames all the variables in the auto-generated genexpr code ?

If my explanation is not fully clear for you or you need more details, I can try to explain better... :)

It's a bit hard to follow, because I'm not sure what you mean by blocks. If you mean visual patching, why not just disconnect the output patch cords. If you mean codebox, you can easily disable sections with /* */ block commenting.

If theres an error showing after pasting code view code into a codebox, can you post it (the entire gen patcher)? Thanks

Hi Graham , my apologies it is very difficoult to say with words...:)

At first can you give more infos about this : you said "If you mean visual patching, why not just disconnect the output patch cords..."

You mean disconnecting the output patch cords should fix something (maybe by doing this, the genexpr-auto-generator is forced to "re-organize" its code ?)

Then, below I'll try to re-explain my experience/issue with an example, I really wish it could be helpful for you.

PS: with the term "gen abstractions" I mean one or more "gen sub-patches" contained inside a "gen patch".

Example:
I have a simple gen patch made using the visual patching approach (blocks connected with wires).
Then, I want to obtain the corresponding genexpr code of that patch/abstraction, so I can replace the whole patch/abstraction with a single CODEBOX piece of code.
So I go inside that patch, I press the "C" icon on the right, I get the corresponding genexpr code, I copy/paste it inside a CODEBOX object/block.
I reconnect the patch inputs/outputs to the in/out of CODEBOX and everything works fine, as the same as it worked when that patch was made using gen objects.

Now, I repeat the same procedure with a very COMPLEX gen patch/abstraction (again, using blocks connected with wires), a gen patch/abstraction containing 10s+ of gen abstractions (sub-patches) inside itself.
So again, I go inside that COMPLEX patch/abstraction, I press the "C" icon on the right, I get the corresponding genexpr code, I copy/paste it inside a CODEBOX object/block.
I reconnect the patch inputs/outputs to the ins/outs of CODEBOX and this time if I play that patch/abstraction, it has a totally different behaviour (malfunctioning like this for example: parameters values are not scaled properly as they were where the same patch was made using gen 'objects').

In these days I noticed that if I repeat the procedure above (substituting gen blocks/wires with the equivalent auto-generated genexpr inside a codebox) for ANY SINGLE abstraction contained inside the main abstraction, and AT LAST I do it also for the main abstraction itself, some issues seem to disappear (the genexpr code is generated correctly)...

I really hope my infos can be helpful for future improvements, :)

I think I understand. If you could post the actual patcher, I could look into it.

However, I still wonder -- why do you want to convert the entire patcher to a codebox? It will not be more efficient, and if you built it by visual patching, I presume visual patching will be easier for you to continue working with.

If you want to compare with sections removed, you can just delete them, then undo :-)

Hi,

my apologies Graham, I can't provide the patcher since it is a HUGE patcher/abstraction and it is made for a commercial product.

My final scope in converting from 'visual patching' to Codebox is that I'm adding the REAL-TIME process/sleep functionality for different portions of the code/software (not just //commenting code :)).
And this can be done only using genexpr DIRECTLY.

By the way, here's the fact: I'm pretty sure (99%) that all of this malfunctioning/issues are due to a 'conflict' with the automatic naming/renaming of gen_variables.

When using 'building blocks and wires' everything works fine because variables are correctly named/renamed using the internal gen~ engine "auto-genexpr" generator (counter).

For example, from a 'blocks and wires' gen patcher, gen auto-generates genexpr variables (and expressions, etc...) named :
"gen_1, gen_2, ..., gen_100,..."
and/or :
"mul_1, mul_2, ..., mul_100,..."
and/or :
"div_1, div_2, ..., div_100,..."
etc...

To simplify everything in my explanation below, let's consider a case/patcher where all variables are named "gen_" + a number.

The issue happen when picking genexpr from a Codebox and converting variables names.

When using Codebox, it could happen that some variable names used INSIDE a Codebox are already used in other areas of the patcher.
This may cause a 'conflict' between names of existing variables (auto-generated from visual patching) and names auto-generated from Codebox objects. For 'conflict' I mean they spot the same name, and then their values OVERWRITE each other.

Maybe to fix this, when the variable names are picked from a Codebox object, a different operation should be done, for example:

Step #1 : pick the original variable name (gen_799) used INSIDE Codebox. At this point (as already happen) (also for runtime), gen engine needs to rename that variable, in order to be used OUTSIDE Codebox, in the main gen patcher.

Step #2 : instead of auto-renaming it to (gen_800), rename it to (gen_799_fromCodeboxNumberOne).

(obviously "_fromCodeboxNumberOne" is just to make an example, other markers can/should be used instead, for example "_01"," _02", so the final name will be "gen_799_01", "gen_799_02", etc...).

I propose this because (gen_800) variable name may be already used by another abstraction/sub-patch inside the main gen patcher!

99% of the times, variables are correctly named with the current gen internal auto-counter. But when a patcher is VERY complex and it picks code also from a Codebox where vars are internally named (gen_897, gen_78628, etc...), when the auto-genexpr-generator generates the final gen~ code of the main patcher (before runtime), an error may occur and some variables could be not 'named to be 100% unique', as it should be. And then some variables value may OVERWRITE other's having the same name.

I wish the issue scenario is now more clear to you Graham, (I made of my best with the explanation :)) for any additional clarification just ask, I'll be happy to help you improving gen~.

I wish you/Cycling74 Team will keep the GREAT work you already made with the amazing gen~ !

PS: the Rule I suggested above in my previous post :

renaming "gen_799" to -> "gen_799_01" , "gen_799_02", etc...

instead of

renaming "gen_799" to -> "gen_800", "gen_801" etc...)

should be applied only in the case of picking genexpr code from a Codebox.

This should be safe and don't generate issues (if I'm missing somethig just let me know).

Does the name clashing happen if you select the entire top-level patcher and paste its codeview into a new gen~'s codebox? If so, this is a bug that will need to be fixed. That's why it would be helpful if you could send me a patcher (you can send it privately to graham @ cycling74 dot com if you don't want to share it).

Otherwise, I think what you are using the codeview for might not be something fully supported. The codeview is first and foremost a patching aid, to help understand what the patcher is doing . It is actually showing the variable renaming (and code re-organizing) that happens among the earlier passes that convert the patcher into machine code. The renaming is a necessary step and will always happen in this way. The codeview is also secondarily a convenience to guide how to use genexpr, and to allow copy-pasting into a new gen~ codebox. As you see the variable renaming will not make this the most readable code, but this isn't going to change.

Hi Graham,

It's a very strange issue... I did as you suggested :

1- I have my HUGE patcher. All works great. No errors. No inaccuracies. When I turn DSP engine "On" (on MAX) everything works great. No bugs at all.

2 - I don't modify anything. In my TOP-LEVEL gen~ patcher, I press 'C' on the right side. Now, genexpr code is displayed. I copy all the 5000+ lines of genexpr inside a codebox. I connect codebox ins/outs to the main ins/outs off the patcher.

NOW I TAKE TWO DIFFERENT WAYS (I'll do point 3A or point 3B separately):

3A - From previous point (2), I disconnect all the "patching blocks" (previously used, currently not used) WIRES from the main outputs (BUT ALL THE DISCONNECTED "patching blocks" are still present in the patcher ! ). ONLY Codebox is connected to the outputs.
In this scenario, everything works FINE!

3B - From previous point (2), this time I DELETE ALL THE "patching blocks" (previously used, currently not used)WIRES+BLOCKS, with the exception of the Codebox (where the equivalent, auto-generated genexpr code has been copied in point(2)). Codebox is now the only 'gen block' present in the patcher and connected to the outputs.
In this scenario, THE BUG HAPPEN!

By the way, in the next weeks I'll try to find out some time to isolate the bug, so I can be more specific on this issue (in what circumstances it happens exctly) and then let you know. If you/C74 team have any idea of what the issue could be, please let me know.

Please try this:
1. select entire top-level gen patcher
2. open the codeview (C icon)
3. copy the code in the code view
4. make a new patcher
5. make a new gen~, and open it up
6. delete the default in1/in2/+/out1 patcher contents
7. create a new codebox
8. paste into that
9. turn on audio

Does it work?