shOPrtcut everything

Hi Superstars

Puuuuulease give EVERY op a Global Op Shortcut parameter!

And for “Text DATs” make this return the mod() so we can do

op.AllTheCode.woteva()

What Would Python Do :1st_place_medal:

Thank You

Hi @aaauser1969,

Global OP Shortcuts should be used sparingly as they have to be unique in a project - so copying operators or replicating / cloning would become hard to manage.

For easy access I would recommend Extensions or Internal Operators.

cheers
Markus

No.

Neither of these solve the problem.

From The Developer and especially The User perspective, what I request would be invaluable. Developing would be faster, cleaner and more readable.

To test TD (before buying), I’ve created a (kickass) app driven by params which are, in turn, driven by channel data from all kinds of sources: sensors, audio and time. The Cherry On The Wow Cake here would be a fast and friendly way to bring Functions into the mix.

E.g., It would be beautifully pythonic if I could set a param expression to op.code.mySine(). Obviously, we’d need to manage singularity (doesn’t TD already do that anyway) so there would be no bugdrama.

The main reason I LOVE LOVE LOVE the work you’ve all done so far, is the creative freedom and raw gfx power it gives us. But that winning design strategy oddly fails at certain points and that’s a real shame.

While I fully understand the hierarchical nature of COMPonents, there really is no need to juggle that when Developing and especially when Using.

Think about it; if I visit your house, I don’t need to remember the blueprint of the building to find the toilet :wink:

Thank You

Let me just say as someone who has built also some kickass apps, global OP shortcuts are not as good as you think they are. Sparingly they can be used, but I would even argue that they should not be used by humans and only in a generative context.
The main issue with global op shortcuts is that there is no governing entity, and thous no central source for them, making them exremly hard to debug/follow for any project that is more then some parameters.
In the moment it might be easier to just write op.code.mySine() but rembering after a week of not working on it, it suddenly becomes unclear.

But even then, you could do the described behaviour with extension no problem!

Sure, this might result in some legwork for you in defining this properties, but even that can be done in code.
With the upside of being consice.

Again, have to argue against this as “juggling” this is giving a project structure, otherwise it resolves in complete chaos.

2 Likes

@alphamoonbase is totally right.

@aaauser1969 even though it might seem to you like a good idea now, it definitely won’t seem that way later on (once you dive deeper and start building stuff). :slight_smile:

Extensions save the day! Phewoohoo!

There’s Always A Solution On Moonbase Alpha :muscle:

In defense of my arg however… I see your point- a casual user littering fields could cause chaos but if you saw my use case, you might reconsider. In a live performance situation, you don’t have time to type out hierarchies.

I plan to send it to you soonish anways… it could be Thee App that makes Touch a household name. Really.

Respectfully, ask yourself if you are set in the Architects Paradigm. If I were in charge of TD, I’d be nervous too but you’re- clearly- very clever and capable of providing stability plus magic.

Although this is my first real TD Network and serious dive into Python, I have 30+ years of commercial app development success and have learned that the User Experience is paramount.

Thank You