you are able to do the full-patch randomization immediately.
Not sure if you could do something with the IML upon creation, but seems like it would be a huge undertaking to
modify the entire behaviour up-until this point.
I am not sure, would this cause every module to have to be re-built with the option then set to Off?
Also if this is the case how would it affect current library patches?
Possibly easiest way would be to make it so the User must build in a sub-patch, and then can hardwire a Randomize node to the whole subpatch, or if within a subpatch if hardwired and hidden it will randomized. Also seems quite tricky rules, but wouldn't seem to force any modules or library items to change, besides the sub-patch coding??
-s
Statistics: Posted by sephult — 22 Dec 2017, 10:17
]]>
Statistics: Posted by rlgsbt — 22 Dec 2017, 08:25
]]>
I have found so many great sounds and tools with "pure chaos"...... this could be called serendipity
BTW, my opinion would be to have a random for the whole patch, because we have an inlet "can be randomize" on every module who can be randomize. Maybe, by default, each module must be in "can't be randomize" position to avoid any problem.
This option, like the "reset" option we put for the whole patch is very usefull, and it doesn't use any cord, for a big patch it's so much better
Statistics: Posted by SylvainT — 21 Dec 2017, 21:18
]]>
Now if I decide to force-wire a randomize function and the item is hidden...I believe I should be able to modify it while it's hidden.
-s
+1-s
Statistics: Posted by oli_lab — 21 Dec 2017, 19:06
]]>
Back in HH2 (around early 2016) Senso was doing some work with the Randomize.
Originally subpatch items would not randomize or have a full-randomize of the patch either.
I believe we had talked about the hidden item randomize as well, and he was aware...but I don't believe it was a bug...but by choice.
I would assume it was to protect unintentional modifications.
I would still agree that I would prefer the option to randomize whatever I would like....even if it was by a forced node.
So I would have to agree in the context of a full-patch randomize...if the item is hidden then possibly it shouldn't be randomized.
Now if I decide to force-wire a randomize function and the item is hidden...I believe I should be able to modify it while it's hidden.
Now if more people request, maybe this can be modified.
-s
Statistics: Posted by sephult — 21 Dec 2017, 16:17
]]>
Also I don't see the point in randomizing a whole patch. That's pure chaos.
One should use the inlet anyways. You can also use a trigger from the "Random Integer" Module for example
to randomize values per button. I do this all the time.
Statistics: Posted by lytz1 — 21 Dec 2017, 14:36
]]>
Statistics: Posted by rlgsbt — 21 Dec 2017, 14:18
]]>
And inlet doesn't work as well. Here's an exemple :
Statistics: Posted by rlgsbt — 21 Dec 2017, 14:09
]]>
Normaly would work with inlet
Statistics: Posted by SylvainT — 21 Dec 2017, 13:24
]]>
]]>
Hi,
The "randomize patch" fonction only works with items wich are visible (Usine Hollyhock Win64 3.0.153). If you hide an element (matrix, fader, button, etc.) it doesn't work anymore.
that's right and it looks like a bug...The "randomize patch" fonction only works with items wich are visible (Usine Hollyhock Win64 3.0.153). If you hide an element (matrix, fader, button, etc.) it doesn't work anymore.
I try to randomize some fader inside a subpatch and they don't
Statistics: Posted by oli_lab — 20 Dec 2017, 19:14
]]>
I need to randomise 12 different parameters with only 1 trigger, and I jus need to see 1 button.
PS. it also doesn't work in pop up if you hide the popup !
thanks
rlgsbt
Statistics: Posted by rlgsbt — 20 Dec 2017, 10:31
]]>