Because I don’t want to. I’ll just use a different way where this isn’t necessary.
Widgets have internal IDs that GP uses. How would it work if everything relied on users naming them?
You can see them in the gig file xml.
Ok, and you want use ID’s in scripting instead of handles?
That will not work as soon as you import a rackspace.
The ID’s are not starting by 1 for each rackspace.
Each widget gets a new unique ID within the gig file.
That would be nice in some cases. With functions to enumerate all widgets in a rackspace.
Although that idea was not so much about scripting, but about extensions. @dhj once suggested that I need to make an extension instead of using scripting for what I did. So I looked into it and found there’s no benefit because I would still need to manually give handles to widgets, therefore making all the code non-reusable.
And with ID’s this would work?
Depending on how it’s implemented, I can think of some ways
Starting with, press a button in an extension screen, get the list of all widgets, show them with their label text, parameters they are controlling. And assign to whatever the extension is doing.
I am not sure, if that is a good way.
With handles it is working, right?
The only thing you have to do is give widgets a handle.
But even without that, a better way of giving those handles would also go a long way
Like, show the widgets in a tabular format, with a column for handles. Selected row highlights the widget. That would be way easier than the current way.
Which is an extremely cumbersome and inefficient way that I can only compare to toothache. If there’s a thing I hate about GP, it’s assigning handles to widgets.
dhj
A menu? This would be huge. Do you want to be able to click on things?…Candidly, it would not be a big deal to create a “report”…
Would it be easier if you could just right-click on a song part directly and open the actions from there without having to go into the song part properties dialog first?
By “menu item”, I mean to generate a text file, like generating a log file for troubleshooting purposes. It could open, like a script editor opens, but it would be read-only.
Is there a good reason not to set the PC number like the original poster recommended, just before you recommend using Actions? I used to do it that way and it seemed to work.
That method had the benefit of being “at a glance.”
Is the reason that when one creates a new Set List that uses existing Songs that one would need to set the PC numbers for each Song again, manually? If so, maybe the solution would be to add a checkbox…
Use PC setting for this song across all setlists.
Something like that could differentiate the old method from the new.
Regarding right-clicks, I’m generally a fan, especially when they are used effectively throughout an app.My favorite DAW and Video Editor for ease of use and efficiency was Vegas. (Except that MIDI was added as an afterthought. It started as an audio editor before the video people took over.) You could right click anything and the most likely task would be clearly named at the top of the list. By contrast, I’ve been using Logic, Final Cut, and Motion for a decade, and I still look to tutorials for basic tasks.
Gig Performer is great in its consistency of the user interface. Basic tasks are intuitive. It uses right-click when it seems like a logical thing to do, but it doesn’t have a “right-click everything” approach. It begs the question of, “would a user think to right-click this?” If so, it’s a great tool in your UI toolbox.
I like handles,
I compare that to entries in a host file.
IP addresses and logical names.
When a widget would be deleted and created again it would get a new ID.
With handles just enter the correct handle name and the script is working again.
In a hosts file, you have everything in one place
Handles are a pain in the butt because of experience of dealing with them
First, it’s just too many steps to get to them - go to edit mode, select widget, select Advanced, type
Second, if you accidentally type in a handle that already exists, you don’t see it, it just gets quietly renamed after you leave that screen, you don’t even know the new handle
Third, I set handles to use them in a script. That’s on another level of torture - I type in the handle, then need to get to the script editor window (which disappears when I type the handle), then I need to go back, click, type, the script window disappears again
Fourth, in cases where scripting (and therefore handles) is needed, I use it for hiding and showing widgets. If I need to change something, real hell begins. I was adapting schamass’s rackspace for my needs, and had to rename those widgets, and they are stacked upon each other, it was super annoying.
Because it’s all done in various places, there’s room for typos
Finally, widgets make scripts and to a large degree extensions very limited in their reusability because they all rely on manually typed words.
With automatically generated ID‘s you have absolutely no control in scripting.
Depending on how it’s implemented
Not sure I want to continue this discussion though
If everything is fine that what are we talking about here? Ok then.
You can certainly do that — Actions are a generalization with more functionality - but you don’t HAVE to use them if you don’t want to.
OK - it sounded like you wanted a menu to pop up with entries representing information - that was confusing.
So you would like a report like we do do for other things (like widget mappings, plugin assignments, plugins in use, etc)
What should that report look like? Remembering that every song can have multiple song parts each of which could have lots of actions as well as the other information about songs and song parts.
Also, in the next major release actions will be available in other ways as well, so such a report could get really huge, making it difficult to review.
Good question about what to list in a diagnostic summary. It could include a number of stats about a Gig file.
First, I would analyze things that are hidden like actions. It could list the presence of Scripts. For instance, I like scriptlets, because they’re visible. There’s one Global Script, so that’s easy to check. Rackspace scripts are a bit more dangerous because I might do something exceptional and forget about it later. So a list of rackspaces and indication of the presence of a script and its size in bytes could be helpful in troubleshooting.
The report could have helpful summaries for developers, when a user sends you a big Gig file and claims a problem. For instance, the summary could list plugins and latencies. Maybe the latency information could be stored from the last successful load of the plugin, so your team could get the information even if you don’t have the plugin.
So, rather than taking a user’s view, you might take a developer’s or troubleshooter’s view. I might use a summary on rare occasion. You and the developers might use it regularly. The feature won’t gain you sales, but it might help your team improve efficiency.
I thought we were talking about a report specifically for understanding actions. That is not a diagnostic summary
To be honest, if we had needed such a thing for troubleshooting, we would have built it a long time ago .
And that’s why it’s unclear whether it’s worth doing this. Generally we will prioritize features and functionality that will benefit the vast majority of customers. If it really is the case that many customers are specifically struggling to manage actions, then it may make sense to figure out what would help.
1 Like
One disadvantage to using an Action in the first Song Part, rather than using, “ Send program change number when song activates” in the Song dialog…
When using the Up Arrow button in the setlist view, we go to the last part of the previous song, rather than the first part. This would not send the PC message, since the Action is only in the first Song Part.
Are there disadvantages to using “ Send program change number when song activates” in the Song dialog?
Also, it seems that the Left and Right keys aren’t used in the Setlist View. These could possibly be used to go from Song to Song (always the first Song Part). Graphically, it aligns with the Song Title area at the top of the page. Of course, this might not be viable as there could be focus issues that I’m not considering. This is an “idea”, rather than a feature request. 
I agree.
The core issue for me is that using Actions for sending PC messages is hidden. And when choosing the next PC number, my decision hinges on previous assignments. A summary would be a bandaid.
If there are no specific issues with assigning the PC number in the Song dialog, then I can just use that method. Your original post made it sound like it was a bad idea, but I might have read too much into it.