So I’ve come across a strange anomaly, I’m working on a subpatch, of a subpatch with several instances so
patch->sub patch (3 or 4 copies in Patch)-> subpatch2 (again 3 or 4 copies in subpatch)
So when I open subpatch2 quite a few load into tabs, which can be annoying as you don’t know which one your working on, maybe the solution would be to open only the one you click on, but I imagine that may be tricky as they’re all copies of the same instance?
Anyway back to the point, I get lots of scroll bars, that dont relate to the patch window, but appear anyway…
Also I just had trouble copy and pasting something into subpatch2, and also when trying to create it manually ie an io box and connecting it to an object, it wouldn’t let me first time, I minimised and reopened subpatch2 and I could connect, but something is amiss there…
The attached bug.zip, doesn;t demonstrate the problem but does get quite sluggish when pasting things in to the subpatch2, I’d imagine its a memory thing with too many windows open…
I know dont use so many subpatches, but I’m build a nest tree thing, I don’t think theres another way, but it is a prototype, I’ll find out when its more finished!
:)
Actually as an addendum, R nodes, still loose their assignment if theres not more than one of them and so haven’t been selected from a drop down list, seeing as you’ve fixed enums, fancy a look at them too?
Or is vvvv going to have to stop being a beta if you fix all the things we know and love like that :P hehehe
Thirds the charm, so they say
I’ve just reopened my patch, finding the r missing, and now I’ve noticed the io box I used to store the dir path is misbehaving, I’ve pointed it to a folder on my desktop, and redone that, using the file browser pop up when clicking, the patch is saved 2 directories up from the Media folder, but vvvv has decided it is the root of all paths… Drag and drop works, but if selecting with a browser does, there’s not much point in opening a browser when you click in the box!
ad 1)
i can only confirm this problem without being able to offer any workaround. vvvvs gui can obviously not deal nicely with such many patches opened. especially if you also have finder opened. closing finder improves the situation for me in your test scenario. still, yes, a problem.
ad 2)
R nodes have the still known issue that they will loose their receiver-enum on next startup if you don’t manually select it at least once. so when creating a receiver that is fine with its default enum, still rightclick the pin and select the enum once. can you confirm it works like this for you?
ad 3)
this is a problem we are aware of. a labeled IOBox string connected to a pin of subtype filename or directory (ie. the subdir nodes input in your case) tries to resolve a path using the location of its parent patch. so selecting the path via rightclick from outside of the patch (via the respective pin) should clarify this. no?
ad 4)
no idea either, doesn’t look harmful though.
