I was trying to use a combobox but the scroller width can only be controlled in the close combobox, not when it opens.Also the height of the open combo is set to the height of the screen. So I decided to use a popup window and a list box instead.
The popup window has "show popup" and "hide popup" trigger inputs.However they both behave the same and toggle showing and hiding the window. If that is the case, why have separate show and hide inputs ? This means there is no way from a script to guarantee the window is open or shut ! And there does not appear to be a way for the script to be told when then window has been opened or shut by the user.
Anyone scripted popups who can help me out ?
Simon.
scripting popup windows
Another thing you can try for certain items is the Where option. You can make things invisible or visible.
I agree, as far as feedback, if you are completely programming from script then yes the approach becomes difficult, as you expect to be able to control all aspects.
Yes I wish in some cases switches were completely standard rather than pulse buttons, at least if it was a switch you could verify the switch to have an assumption the popup was open.
So the best bet I could think is to create a switch that does the toggle on both the on and off positions. Set the popup in a known state to start with (default off), and read the switch. You could probably stabilize the triggers with some tweaking for reliability. The only other problem you will have is if the user manually closes the pop-up and knowing the state there. So to prevent this make sure you disable the pop-up header.
-S
I agree, as far as feedback, if you are completely programming from script then yes the approach becomes difficult, as you expect to be able to control all aspects.
Yes I wish in some cases switches were completely standard rather than pulse buttons, at least if it was a switch you could verify the switch to have an assumption the popup was open.
So the best bet I could think is to create a switch that does the toggle on both the on and off positions. Set the popup in a known state to start with (default off), and read the switch. You could probably stabilize the triggers with some tweaking for reliability. The only other problem you will have is if the user manually closes the pop-up and knowing the state there. So to prevent this make sure you disable the pop-up header.
-S
"Every act of creation is first an act of destruction." -Picasso
-
sm_jamieson
- Member
- Posts: 559
- Contact:
I don't think the popup window has a where property - I did think of that !
The thing that looks like a bug, is that there are separate show and hide trigger inputs. As if two software teams did not talk to each other !
By the way, I am fairly new here. What is the relationship between this forum and the Usine designers ? I see different levels of members and people who are "community". Is there any level of open source in the project ?
Sorry if this is in a FAQ somewhere.
Simon.
The thing that looks like a bug, is that there are separate show and hide trigger inputs. As if two software teams did not talk to each other !
By the way, I am fairly new here. What is the relationship between this forum and the Usine designers ? I see different levels of members and people who are "community". Is there any level of open source in the project ?
Sorry if this is in a FAQ somewhere.
Simon.
-
sm_jamieson
- Member
- Posts: 559
- Contact:
Oh, just a thought. I have not looked into IML, but can you use that to better control the popup window ?
Simon.
Simon.
Hi sm_jamieson,
http://www.sensomusic.org/wiki2/doku.ph ... sensomusic
The above link is the bug-report system, as well as some more information on the Usine team.
So as far as the pop-up, I assume originally from like V5 or early HH version it was applied as a two button and had probably changed without removing the module inlet. nay-seven or senso could probably give the reason why. I would send in a bug-report for this, usually they are pretty good at explaining the reason why or not.
As far as being an open-source project (the base application) it is not. But there are plenty of tools.
In addition as you have found:
The IML is an exposure of the some of the internal messaging language to allow dynamic creation of modules by program.
For Patch editing:
It does allow modification of the base context menu that comes up when wiring. Say you always use an X-1 module like I do. Well you may modify this context menu so that it is available when you wire just combo or list boxes. I have also used this to modify plugins to include wiring and bus modules whenever a plugin was added to a patch. These IML text files can be located within the templates directory, as you can see some additional ones by ethnix73 such as x-Outlet-All-Trace which adds the "Trace" to all wiring nodes when applied. Add any wire and the context menu at the bottom will give the option to add a Trace. These files are read during the opening of HH, and will help modify your patch editing environment as well as patching.
Dynamic:
There is also the ability to access the IML via Send Usine Internal Message module, or via FastScript syntax.
I have done some IML work, but not too much in the depth of dynamic operation during patch/performance interaction, however more so as a development/interface enhancement. I would suggest maybe trying the SetValue and Query option on the pop-up module and see what you get for a response. I assume it is just the inlet value and since it is a toggle probably will not be much info. Also there are options to resize and position the windows using the IML, this might be of use. Possibly size manipulation to Hide/Show could be of value.
I assume the same interaction would be available as manipulating the base module Height/Width or percentages. Might be something to try out first using Knobs/Faders and if looks promising then either script the IO or direct control via IML.
http://www.sensomusic.org/wiki2/doku.ph ... l_messages
Sounding as you are more likely a software programmer by trade?, this might be an area you would be interested in.
I am just assuming, as I am a hardware/software technician
Been my career for many years helping software and hardware integration.
There is the SDK to create modules as well that might be interesting to you.
http://www.sensomusic.org/wiki2/doku.ph ... _hollyhock
I have not dove into the SDK yet besides a glance, I am not sure the extent of control regarding interfacing or pop-up and application interaction, however for a programmer and for efficiency this might be the route to go.
As far as relationships, the Usine team is directly involved with forum handlings. It is not like most corporate applications where you never get information or direct responses from the designers
However do know, due to the small team they are very busy and at times cannot respond immediately or to every post.... however they do see them (not just some public interface person). There are users who have been deeply involved for quite awhile and others who have involvement and development support, as far as "levels" of open-source base application access there is not any that I know of.
If you have a suggestion or question, send in a bug report/feature request, or post in the forum.
-S
http://www.sensomusic.org/wiki2/doku.ph ... sensomusic
The above link is the bug-report system, as well as some more information on the Usine team.
So as far as the pop-up, I assume originally from like V5 or early HH version it was applied as a two button and had probably changed without removing the module inlet. nay-seven or senso could probably give the reason why. I would send in a bug-report for this, usually they are pretty good at explaining the reason why or not.
As far as being an open-source project (the base application) it is not. But there are plenty of tools.
In addition as you have found:
The IML is an exposure of the some of the internal messaging language to allow dynamic creation of modules by program.
For Patch editing:
It does allow modification of the base context menu that comes up when wiring. Say you always use an X-1 module like I do. Well you may modify this context menu so that it is available when you wire just combo or list boxes. I have also used this to modify plugins to include wiring and bus modules whenever a plugin was added to a patch. These IML text files can be located within the templates directory, as you can see some additional ones by ethnix73 such as x-Outlet-All-Trace which adds the "Trace" to all wiring nodes when applied. Add any wire and the context menu at the bottom will give the option to add a Trace. These files are read during the opening of HH, and will help modify your patch editing environment as well as patching.
Dynamic:
There is also the ability to access the IML via Send Usine Internal Message module, or via FastScript syntax.
I have done some IML work, but not too much in the depth of dynamic operation during patch/performance interaction, however more so as a development/interface enhancement. I would suggest maybe trying the SetValue and Query option on the pop-up module and see what you get for a response. I assume it is just the inlet value and since it is a toggle probably will not be much info. Also there are options to resize and position the windows using the IML, this might be of use. Possibly size manipulation to Hide/Show could be of value.
I assume the same interaction would be available as manipulating the base module Height/Width or percentages. Might be something to try out first using Knobs/Faders and if looks promising then either script the IO or direct control via IML.
http://www.sensomusic.org/wiki2/doku.ph ... l_messages
Sounding as you are more likely a software programmer by trade?, this might be an area you would be interested in.
I am just assuming, as I am a hardware/software technician
There is the SDK to create modules as well that might be interesting to you.
http://www.sensomusic.org/wiki2/doku.ph ... _hollyhock
I have not dove into the SDK yet besides a glance, I am not sure the extent of control regarding interfacing or pop-up and application interaction, however for a programmer and for efficiency this might be the route to go.
As far as relationships, the Usine team is directly involved with forum handlings. It is not like most corporate applications where you never get information or direct responses from the designers
If you have a suggestion or question, send in a bug report/feature request, or post in the forum.
-S
"Every act of creation is first an act of destruction." -Picasso
Who is online
Users browsing this forum: No registered users and 31 guests
