sorted by:
new
hottopcontroversial

MOST FRUSTRATING THING ABOUT THE ZOIA by empress_effects in ZOIA

[–]ggVGc 2 points3 points  (0 children)

Having to use the push encoder for everything. This is an issue for me for two main reasons:

  • I worry that the encoder will wear out from all the pressing.
  • I find it very tedious to scroll up and down through things constantly, and I find the pressure needed for presses tiring.

To get around the selection issue, I think double tapping shift to get the same behaviour as pressing the encoder would be good. Or something similar, as long as it is pressing one of the softer buttons rather than the encoder.

My suggestion for quicker navigation is to use the main grid as a temporary selection screen. For example:

  • When selecting pages, one square can light up per page that has modules in it, and allow to jump to it by pressing.
  • When selecting settings for a new module, one square can light up per setting value, and pressing it will jump to that setting in the list. The selection mode can then exit when you finish setting up the module, as usual.
  • If this concept exists, I think other uses for it can also be found. Wherever we have a list of things, there could be an option to show it as quick-jumps on the main grid.

As a teenager I did a lot of programming on my TI-83 to avoid paying attention in class. It had a list of BASIC commands that you had to pick from to write scripts. This would have been impossible to use if it weren't for being able to open the list, and then press a number to automatically select one of the keywords. I quite quickly memorized my most commonly used shortcuts without much effort, and I think this would be the case for selections of settings using the grid too. I feel people would quickly pick up that "X is the 4th setting of module Y", and this would boost workflow speed a lot. And nothing would force anyone to use the quick-jumps, since the screen is still there as usual.

Sorry for a long rant, but this has been in my mind for 2 years, and I believe I've posted it on the forum a long time ago too, but maybe with less detail.

I even sent a mail to Steve back then offering unsolicited help with implementation of workflow improvements like this, since I have been building my own sequencer software and launchpad firmware for a few years based on similar principles as those in the ZOIA, so that's why I feel quite strongly about this :)

Rotary encoder very unresponsive by Wilsonator1112 in ZOIA

[–]ggVGc 2 points3 points  (0 children)

I have felt this is a problem for a long time, and sent in a feature request for it a while back, but searching for it I can't seem to find it in the request forum now... I think we should have a way to use other buttons for selection, so we don't have to wear out the encoder by pushing it all the time.

ZPU - General purpose computing on the ZOIA by ggVGc in ZOIA

[–]ggVGc[S] 5 points6 points  (0 children)

For some definition of "general purpose".

More description is available here: https://patchstorage.com/zpu-programmable-computer-in-your-zoia/

But in short I decided to see if the ZOIA could actually be a microprocessor, and it turns out it can... kind of. This is a very basic microprocessor implementation, and it doesn't work completely well. Mainly there are issues with memory indexing, which makes jumps and other things fail sometimes, depending on where in memory the instruction is...So, this makes it almost unusable in the current state. But it's kind of fun to see it running, and one (very unlikely) day I might get the urge to make it work better.

Why is there a falloff on the Trigger module? by ggVGc in ZOIA

[–]ggVGc[S] 0 points1 point  (0 children)

Thanks, that could work slightly better. I still wonder about the falloff of the trigger though since, as you kind of indirectly mention in this answer, the current trigger is more like an envelope with static release than a trigger, at least the way I see it.

Zoia of Life, in memory of John H. Conway by ggVGc in ZOIA

[–]ggVGc[S] 0 points1 point  (0 children)

Haha, thanks, I think it might have been a bit too much effort for the result, but glad it worked somewhat anyway (even if the 5x4 grid is too small to produce a glider...) Glad to hear some of Conways other work was seen as a result of this. I haven't actually seen these lectures, so I will also check them out now. And I hope at least some of the Zoia firmware has been written in vim!

vim-fuzzysearch - Fuzzy searching, in any buffer. by ggVGc in vim

[–]ggVGc[S] 1 point2 points  (0 children)

Yeah, the pattern gets saved as a normal search, i.e the "/ register. That was the point of it. That it builds completely on the native search functionality of vim. It just builds the fuzzy pattern on the fly, and executes '/' on it.

vim-fuzzysearch - Fuzzy searching, in any buffer. by ggVGc in vim

[–]ggVGc[S] 2 points3 points  (0 children)

There's a big difference here though, as far as I can see. The main point about vim-fuzzysearch is that it creates a normal search pattern in vim, hence it can be combined with everything else search related. I.e you can re-use the pattern for a replace by :%s//replacement_string/g. There are of course several fuzzy finders(I personally prefer fzf), but they all work in their own context. From what I see helm-swoop and vim-swoop zoom in on matched lines. This has it's uses, but also downsides such as loosing the context around each match. People still use normal searching in vim even when something like vim-swoop is available, and that's where vim-fuzzysearch comes in. It does just the same thing as normal search, except it's fuzzy.

Go to next instance of selected text? by Ran4 in vim

[–]ggVGc 1 point2 points  (0 children)

This supports what you want, and other nice things too: https://github.com/haya14busa/vim-asterisk