Rack v1 development blog

What should be used instead of void randomize() override {} to not randomise a parameter that is.

params[...].randomizable = false

2 Likes

Seems like a better way to do it. Is that in the process() or the config part?

In the Module constructor.

1 Like

in reference to NVGcontext:

Just to point out if you manage to forget about this change in NVGcontext (see op) it will not throw any warnings or errors at compile, it will show errors in the module constructor though which look like there is something wrong in there instead, tripped me up anyway!

I have wanted this so much. Thank you!

Closing my issue I opened today. This is exactly what I need.

Cool Breeze

I’ve been playing with the concept of making the rack infinite in all four directions, rather than just the bottom and right. Any thoughts?

8 Likes

Sounds good to me.

Oh that would be cool though you would possibly have to have a centre point or (0, 0) I feel to get back to if you have many modules. Though in saying that now if you were to add a way to get back to that point say the first module added perhaps a coordinate system with or maker to scroll to would be good also.

3 Likes

As an addition to making Rack infinite in all four directions it would be helpful if there were an easy means of locking the current window in place to prevent unintentional scrolling or jittering like movements when performing live or recording videos etc. Maybe something like a Padlock button in the toolbar to lock the display? Currently the 2 way scroll assists with this but that method would not be available should infinite scrolling in all 4 be added.

3 Likes

Do you mean scroll by inner window. Say arrow keys would go to the next inner window multiple. That would take zoom into account.

No… I simply meant locking the ‘window’ itself so no ‘accidental’ scrolling (or that jittering that occurs when dragging cables on a Mac at least) could take place. Though, your idea as something else, would seem to be a good one in addition to a lock.

1 Like

I feel like it’s solving a problem that doesn’t really exist. The biggest problem it half helps is if you want to move an entire row [or more] to the right/down, and you’ve built up around the top and left already, you can just scroll left/up a bit. But that would be easier to fix with some way to just move multiple modules at a time.

2 Likes

I would love this, because I almost always find myself wishing I could add a row above where I’ve already placed modules.

In the possible case that you implement a feature that allow see all the modules in the patch I wonder how to see all the modules in a infinite “canvas” with a limited zoom out?

It sounds good actually, will give greater freedom in building a patch out the way you want it. I’m thinking there must be some disadvantages, but I can’t actually think of any right now.

I might want an option to go right and down as it was, as that is how I tend to patch, but that is just me, that way the top left is always ‘home’ so to say… but yes, if that is a choice, then I am all for it :wink:

3 Likes

Not sure about the usefulness of fuzzy search. I’ve been writing “vca” in the module browser and I still get 28 of the 31 modules installed on my system. And consider that I only have Fundamental and Core loaded. It is impossible to find a VCA this way.

A second thing I don’t like: if I click a Tag, and later I want to deselect the tag I can’t easily find it. Simply greying out the others is not sufficient. I’d rather make the others disappear so that I can later click again on the tag, or even better have a cross beside the tag name that easily tells me how to remove the tag.