So people want the feature that you get in song parts but they don’t want to use the feature (song parts) that gives them the feature they want?
That are individual fates
Ah, common… you know what i mean.
It’s not about song parts, it’s how widgets react in two diffrent environments!
I know what you mean, but the feature is there already for song parts.
which would imply the use of the setlist view.
Why not have a consistent behaviour anywhere? (Or at least the option to activate it)
I don’t have a strong feeling about this one way or the other - I’m just trying to understand the need.
But given that one can do this with song parts (along with many other things such as actions, etc), it’s unclear to me how important (priority wise) this is compared to other things that need to be done.
If I was to use an analogy, it would be like somebody using a table view in Microsoft Word and then complaining that the table view doesn’t do everything that Microsoft Excel can do.
Yeah… “the need” for it surely is a very individual thing.
For me personally, it would not be a big pain if it stayed as it is, but i would appreciate it as a “nice to have”, so i can understand if someone asks for it - even if i personally wouldn’t need it that much. I just tried to give some kind of plausible explanation for the request.
Yes - and the question is how important is it for the large majority of users given that this can be done using song parts…compared to other things that need to be done.
This argument will always be valid and can be brought up with any new wish for a feature… in German i would call it a “Totschlagargument” (A reason or argument which will always stand over everything else).
But as i already said: It’s not very important for me personally, so i don’t feel the urge to discuss this any deeper.
It’s good that this is discussed and a decision taken to change it or leave it like it is.
Please allow me to add two things:
- I don’t want to be known as the workaround king, but to help @thirdspace achieve what he wants even with the current circumstances this would be the concept:
var
widgetname : Widget // replace with your widget name
On Variation(oldVariation : integer, newVariation : integer)
Select
newVariation == 1 do // replace with index of the variation (starts with 0)
SetWidgetValue(widgetname,0) // replace with your widget name and the desired value (0.0-1.0)
End
End
- Let me suggest to check that this (intentionally) different behavior of song parts vs. variations be documented sufficiently and clearly enough.
Interesting discussion. Let me explain a request for “Also Reset on Variation Activation” from my perspective - and I accept I am likely in a very small minority here:
Until reading this discussion I didn’t even know what a song part was - I’ve had a quick look and I’m sure they are very powerful, but I have been using GP as a plug-in host and virtual pedalboard for guitar for a few years now and the ‘concept’ of songs has not even occurred to me (yet - give it time!). I simply want to create a bunch of patches (variations) that I can call up at any point in any song, and then tweak if required. This is how I use a real pedalboard in a gig - 8 or so patches to represent the basic sounds I may need - clean, crunch, solo etc. Ideally the chance to add for example delay (or increase delay) if the need arises. So no sound is linked explicitly to a specific song.
I’m glad that there is way to “Also Reset on Variation Activation” but to me (and maybe I am alone here) this feels like a workaround via another GP feature, and would really like a simple way to do this rather than learn a whole new discipline intended for a specific way of performing - seems very ‘sledgehammer to crack a nut’ (not sure that translates in German too well!) to me.
So - how do I make a request to ‘the devs’?
Absolutely….and it SHOULD be brought up with any new wish. Otherwise, how are we (or indeed any development organization) to respond to almost daily suggestions for new features. We would be stopping what we are doing every day because a new suggestion came in and basically nothing would get done.
That is the main reason for pushing back….we need to really understand whether a new suggestion will benefit 90% (say) of users or 10% of users and balance that against other suggestions and their respective benefits to the greater majority of users.
Sometimes it’s obvious and, if we are lucky, it’s a low hanging fruit so we can perhaps interrupt longer feature work to add something quickly but that’s rare. In the case of this particular feature, beyond the core effort to implement, it requires GUI changes to an already extremely cluttered widget options view. We need to seriously overhaul that view before we add anything unless it’s absolutely critical.
Understood completely
The devs monitor and participate in these discussions (I’m one of them!)
Aha! Thanks
Yes - that’s it - a much shorter way to write what I wrote
Personally I don’t use song parts because I don’t absolutely need it. And I don’t want to reduce the display of my panels for displaying additional information like the song title (if this display becomes optional in a future version of GP, I will of course reconsider the use of song parts).
Having said that, if the “Also Reset on Rackspace Activation” option makes sense in the Panels View, it is quite obvious that the “Also Reset on Variation Activation” has its place there too, even if there is a Setlist View workaround.
I have trouble seeing this as a “workaround” — workarounds generally mean doing things that are either undocumented or by using tricks. But supporting variation recall in song parts is not a workaround - it’s an explicitly stated feature/property of song parts.
Having to use Setlist mode when you’re not using it at all, just to have a feature that could logically be accessed from Panels mode, is what I called a workaround. It sounded better than unwanted, but well-documented, constraint.
And the question comes down to, why would one not use setlist (song) mode? Songs and song parts are getting more sophisticated, e.g. song parts now have actions in them as well and more stuff will come in the future.
Rackspaces can be viewed as individual collections of topologies to be used by songs with songparts. There’s a sense in which Rackspaces as a “main” interface may be viewed as legacy.
Just for consideration - I get that it’s very easy to get up to speed just using rackspaces.
I tried to explain it here: