Script V2 - Usine objects
-
sm_jamieson
- Member
- Posts: 551
- Contact:
Script V2 - Usine objects
I have been trying Usine Objects in a script.
When I change the color of a fader in the script, the color changes immediately on the display.
But when the slider value is set in the script, the slider value does not change on the display straight away.
The slider position only moves to match the set value when
1. I set the color of the slider in the script
2. I click on the slider object (not on the slider itself but right next to it).
This seems to be a bug.
Can anyone else confirm they see the same result ?
Simon.
When I change the color of a fader in the script, the color changes immediately on the display.
But when the slider value is set in the script, the slider value does not change on the display straight away.
The slider position only moves to match the set value when
1. I set the color of the slider in the script
2. I click on the slider object (not on the slider itself but right next to it).
This seems to be a bug.
Can anyone else confirm they see the same result ?
Simon.
please send the patch ?
Olivier Sens
www.brainmodular.com
www.brainmodular.com
-
sm_jamieson
- Member
- Posts: 551
- Contact:
The patch has an input fader, and output fader and a change color button.
The input fader is connected to the script and when the input value changes in the callback
the value is sent to the output fader without wires using Usine Objects.
The color button changes the output fader color between blue and red using Usine Objects.
When the input fader is moved the output fader does not move.
If you click right next to to the output fader, or press the color button, the output fader moves to its correct position.
I am using Usine version 5.2.220108
Thanks,
Simon.
The input fader is connected to the script and when the input value changes in the callback
the value is sent to the output fader without wires using Usine Objects.
The color button changes the output fader color between blue and red using Usine Objects.
When the input fader is moved the output fader does not move.
If you click right next to to the output fader, or press the color button, the output fader moves to its correct position.
I am using Usine version 5.2.220108
Thanks,
Simon.
ok, it doesn't work on 5.2.220117 and prior, but fixed now. next release.
Olivier Sens
www.brainmodular.com
www.brainmodular.com
-
sm_jamieson
- Member
- Posts: 551
- Contact:
I have tried in the Beta version Usine Win 5.2.220122.zip and my patch still has the same problem.
Zip file with screen record of the problem:
Zip file with screen record of the problem:
Last edited by sm_jamieson on 24 Jan 2022, 16:04, edited 1 time in total.
not confirmed, works as expected in the latest version?
Olivier Sens
www.brainmodular.com
www.brainmodular.com
-
sm_jamieson
- Member
- Posts: 551
- Contact:
Sorry message crossed over.
I note the fader has a common in and out parameter.
It couldn't be somehow related to that ?
I note the fader has a common in and out parameter.
It couldn't be somehow related to that ?
no, I found the issue, just a matter of graphic update. The script works but the fader is not visually updated.
will be corrected.
will be corrected.
Olivier Sens
www.brainmodular.com
www.brainmodular.com
-
sm_jamieson
- Member
- Posts: 551
- Contact:
Thanks.
I have noticed some things about the Usine Objects list shown in the script (local and global objects).
1. The Usine Objects for a patch are not updated in the list unless the patch or workspace is saved.
2. When a subpatch with a module in it were created and named with Alt-click, and the patch saved,
the subpatch appeared in the local objects list, but did not appear in the global objects list.
3. When the subpatch was given polyphony, the second voice did not appear in the local or global objects list
when the patch containing the subpatch was saved.
4. When the workspace was saved and reloaded all Usine Objects were shown in the local and global objects list.
It seems fair enough to only update the objects lists when something is saved that contains the changed objects
(i.e. save the patch or the workspace). But I think everything in the local objects list should always be included in the global
objects list.
One other thing - racks and patches are only shown in the object lists as rack01, patch01, patch02 etc. rather than by the rack
or patch name. It would be useful if patches could be given a Usine Object symbolic name. Otherwise patch01 could change its
name to patch02 if a patch is inserted, which would break and Usine Objects references for that patch.
I think it should always be possible to locate a patch within the workspace using a fixed name.
Of course, sub-patches can already be given a name using Alt-click or by saving with a certain name.
Thanks,
Simon.
I have noticed some things about the Usine Objects list shown in the script (local and global objects).
1. The Usine Objects for a patch are not updated in the list unless the patch or workspace is saved.
2. When a subpatch with a module in it were created and named with Alt-click, and the patch saved,
the subpatch appeared in the local objects list, but did not appear in the global objects list.
3. When the subpatch was given polyphony, the second voice did not appear in the local or global objects list
when the patch containing the subpatch was saved.
4. When the workspace was saved and reloaded all Usine Objects were shown in the local and global objects list.
It seems fair enough to only update the objects lists when something is saved that contains the changed objects
(i.e. save the patch or the workspace). But I think everything in the local objects list should always be included in the global
objects list.
One other thing - racks and patches are only shown in the object lists as rack01, patch01, patch02 etc. rather than by the rack
or patch name. It would be useful if patches could be given a Usine Object symbolic name. Otherwise patch01 could change its
name to patch02 if a patch is inserted, which would break and Usine Objects references for that patch.
I think it should always be possible to locate a patch within the workspace using a fixed name.
Of course, sub-patches can already be given a name using Alt-click or by saving with a certain name.
Thanks,
Simon.
Hello Simon,
Interesting tonic indeed.
For point 1 to 4, just click compile in the script to initialize local and global objects.
I think your last point is true. Maybe Senso has a reason to do it like that. In the meanwhile, changing that will break all the scripts done before for all users. Not sure Senso could find a compatibility. I'll talk to him this afternoon about that.
Sylvain
Interesting tonic indeed.
For point 1 to 4, just click compile in the script to initialize local and global objects.
I think your last point is true. Maybe Senso has a reason to do it like that. In the meanwhile, changing that will break all the scripts done before for all users. Not sure Senso could find a compatibility. I'll talk to him this afternoon about that.
Sylvain
-
sm_jamieson
- Member
- Posts: 551
- Contact:
Ok thanks.
I think the references using patch01 etc could stay there so nothing breaks but references added to Usine Objects using the patch names. I don't think there is a problem with having more than one reference to an object.
It would be useful if you could detect duplicate references though, say a function that can return the patch ID so the same number would be returned for both duplicates.
Currently I can find a patch by including a named module that does nothing and search for that name in the Usine Objects hash.
Simon.
I think the references using patch01 etc could stay there so nothing breaks but references added to Usine Objects using the patch names. I don't think there is a problem with having more than one reference to an object.
It would be useful if you could detect duplicate references though, say a function that can return the patch ID so the same number would be returned for both duplicates.
Currently I can find a patch by including a named module that does nothing and search for that name in the Usine Objects hash.
Simon.
I add some precision about global objects.
- creating the objects list is an heavy task and is done before the compilation of the script. So if you want to update it, just recompile.
- the more you have entries in the list, slower is the script so we must keep the list as short as possible.
- creating the objects list is an heavy task and is done before the compilation of the script. So if you want to update it, just recompile.
- the more you have entries in the list, slower is the script so we must keep the list as short as possible.
Olivier Sens
www.brainmodular.com
www.brainmodular.com
-
sm_jamieson
- Member
- Posts: 551
- Contact:
Hi,
The patch I posted
https://www.brainmodular.com/forums/dow ... php?id=305
is not working at all in Usine HH5 Win64 5.2.220503 beta
Simon.
The patch I posted
https://www.brainmodular.com/forums/dow ... php?id=305
is not working at all in Usine HH5 Win64 5.2.220503 beta
Simon.
confirmed,
will be solved in the next release
will be solved in the next release
Olivier Sens
www.brainmodular.com
www.brainmodular.com
Who is online
Users browsing this forum: No registered users and 60 guests
