Patch Editor Stuff

[Blaakk]

A few things i'd find extremely handy.

1. A hierarchy map.
Dunno about you guys, but I often get lost when buried in a sub-sub-sub-sub-sub patch, for instance. I do prefix names, but this is a pain when using (and saving) common, reusable sub-patches. A little tree/branch thingy in the top corner would be a huge help.

2. More Patch Editor IML procedures, particularly related to editor graphics/module size and position.
To illustrate, here's one of my subpatches.....



Say I'd like to change the 'on color' of all the switches, like so....


I then have to move this switch up (or the next down) before I can repeat this process with the next module...


But this modules 'on color' pin is is obscured.


And refuses to move to the top when clicked, so must be moved left..

And then must again be minimized, and moved, to remain neat. I know I could automate this using the IML, at least creating the terminal links, but I doubt the positions would be offset to compensate. Maybe SET_MODULE_POSITION/SIZE procedures?

After deleting a wire, the now unused pin remains visible when minimzed...


Also, when 'recreating' a module, any previously connected pins become hidden when minimized and are now only shown when module is at max height.


A few more things currently in my head...

3. When changing a size value of a module that holds values, say changing a multi-midi filter from 16 to 32, an option to NOT reset the values 1-16 would be great, especially if these values are non-sequential.

4, Having two different colours for the two halves of each flux wire, to help determine which side is connected to an input (making any feedback loops in 'mad patches' very obvious).

5. Optional font styles, maybe? Would be verrrry nice.

6. When saving a workspace (or any file with children), if it's racks, and their 'in devices', patches and 'out devices' were saved separately within a mirrored folder structure in addition to being embedded in the .rack file, that would be mega-awesome.

Erm... I'll leave it at that for now.

[sephult]

Hi blaak!

" A hierarchy map.
Dunno about you guys, but I often get lost when buried in a sub-sub-sub-sub-sub patch, for instance. I do prefix names, but this is a pain when using (and saving) common, reusable sub-patches. A little tree/branch thingy in the top corner would be a huge help"

I always thought a "birds-eye" view would be good. Depending on what I am doing, well and if you have interface objects. I taught myself to use the corresponding interface objects and use the "find in patch" contextual menu to help relocate. That's funny because I responded yesterday about this about being "deep" once you get organized.

I know this is not the most ideal way, but possibly if you are working within a patch, You could add a button where you are working while you are patching. I've thought about doing this before on complex patching, so possibly throwing this button on the IB if you are not using or something. This way you are essentially building your own heirarchy that you can "find in patch" as just a temporary build tool.

[sephult]

Actually, This would be a good use of the Toolbox!

In each patch a button could be applied for your reference, you can name the button and place in the toolbox using the "where" option.
Then you will have a floating window to help you navigate common used places.

-S

[Blaakk]

Hey hey!

Great idea! Hehe, the 'find in patch' is probably my most used button! I actually started heavily using the IB, but I reverted back to working in racks for some reason. Can't remember why exactly... Usine trial and error patching has literally been my whole life for a few months now. Big Blur.

But I do remember not being able to reorganize the patches properly. Dragging until it states 'move before/after' sometimes wasn't working for me. Even now patches don't switch positions instantly, only after then maximizing or minimizing either of the patches do they trade places. ***I've just now stopped the Master Synchro On, tried to switch two patches, and it doesn't work. Even after turning the clock back on***. Seems like a bug.

Yeah that was it! I was planning to use arrays of 'spacers'... basically patches containing empty sub-patches (to rid the text) which lie between every patch and then either span the whole screen horizontally or vertically. Actually.... here....




The second spacer is lost with its zero width (ie, I can't select it. Oops), but its still doing its job of forcing the 'D Meters' patch to the right.



Slap a multi variable on 'Spacer A' with a smoother afterwards, and have it glide to its new position.

I more recently planned to use the IML for layout switching, but something like this could be much easier (if the patch positions behave).

But yes... thanks for the Toolbox Tip! I think the synthetic view could maybe venture into the tree-diagram displaying territory. It's not much use to me currently.

Ps, I'm sure somebody must have mentioned this before, would it be possible for subpatches to be arranged in the control panel in a similar fashion to their parents?

Pps.... how the hell do you right click with a touch screen? Am I foolishly missing something? Will that be catered by the 'send mouse message'? Really need to ditch the mouse, I have some kind of repetitive strain injury. Not good.

[sephult]

Cool,

As far as right mouse in windows for touch screen it is usually a long-hold to perform the function.
I am not 100% sure I get your question regarding the subpatches in control panel and parents.

If you are meaning when they are placed in parents etc..I always find problems with that too.
So I think the key is to arrange the subpatch controls first then send the whole subpatch container to the parent to retain the same layout.
I am typically not wanting the container box of the subpatch so I always mess around with these options.

-S

[sephult]

Hey blaak!

Regarding mirror folders for structure of racks that is a good one.
Here is another tip for something for organization.

I have made several folders for my personal folders where I organize things. So say you want a "Favorites" folder, but you don't want to duplicate all the patches you use in that folder. Many other operating systems use Symlinks(or Simlink) which work basically as Pointers instead of copy and paste of the file. There are several programs out there for Windows which will put a Symlink context in your right -click contextual menu in Windows. This way you can make a folder and put the pointer in the folder instead of a copy.

This can prevent making changes to one and not the other, since it is a pointer if you make a change it will reflect in both.

-S

[Blaakk]

The long hold works as normal within the Windows OS, but not within Usine's window/s, which is fine for the most part, but sometimes the context menu just wont appear with a right click.

I just meant 'switching/auto-reorganization' of the subpatches by dragging, similar to the 'normal' patches/racks' behaviour. I'm the same with the containers. They can be confusing with some poly patches, and I deliberately leave decent empty spaces on the right of patches for when unlocked.

Speaking of, the way the elements skeletons (ie when unlocked) lie 'on top' of the patch editor really[i/] needs sorting. It also overlays/obstructs the icons on the left.

Symlinks... I shall check these things out. One can always be more organized.

[sephult]

No doubt,

I caught on to the organization theme and thought I'd share. One of the challenges I am working on approaching as a project myself

-S

[senso]

Hello,
Many interesting suggestions

1) hierarchic map: you're right it could handy. I'll think about, but it will take time.
2) the IML improvement is endless. It will be done slowly, step by step. They are already new IML commands in HH2. The best should be to give me a list of missing IML commands.
But when I see you sub patch screen shot I immediately think that it could be very simplified with a polyphonic approach.
3) I know but the "recreate module" command is made to recreate it from scratch. I'll think about a way to reload old values.
4) different colors in/out. Not easy.
5) yes, planed. Will arrive probably this year
6) not easy to implement.

senso+++