jstrecker's picture

Jaymie (@jstrecker)


  • Vuo Founder
  • Team Vuo
jstrecker's picture

Yes, I think you're right about case-sensitivity being the issue. I'm glad you pointed that out, or it might have taken us a while to guess! The nodes that refer to the library (including Calculate, Calculate List, Make Parametric Grid Mesh, and Make Parametric Points) call it "muParser" when it should be "muparser".

Until we get this fixed, you may be able to work around the problem by renaming the library file:

  • Right-click on your Vuo Editor.app file and choose Show Package Contents.
  • Go to Contents > Frameworks > Vuo.framework > Versions > Current > Modules.
  • Rename libmuparser.a to libmuParser.a.
  • Go to Finder. (For example, click on your Desktop so that the menu bar says "Finder".)
  • Hold down the Option key and select Go > Library.
  • Go to Library > Caches > org.vuo.
  • Delete the folder whose name corresponds to your current version of Vuo (e.g. 1.2.6).
  • Restart Vuo Editor. (It will take longer than usual to start since it will need to rebuild the cache you just deleted.)
jstrecker's picture

This appears to be the same underlying issue as Saving Composition to Node Library does not update relative file paths or copy files.

If you first made (Loyalist )ConvocationGUI.vuo as a regular top-level composition, the Fetch Image nodes would have worked fine because they were referencing image files relative to that composition file (like ../../../../Desktop/LC Convocation VUO Master/Image Elements/GUI_Buttons/Zoom Increase.png). If you then changed it to a subcomposition, (Loyalist )ConvocationGUI.vuo would have been moved to your User Modules folder, and it would then be looking for image files relative to the new location of the composition file — so it would no longer be able to find them.

As a workaround, you can edit the values of your Fetch Image nodes' URL input ports, making them absolute paths instead of relative to the (sub)composition file. For example, change ../../../../Desktop/LC Convocation VUO Master/Image Elements/GUI_Buttons/Zoom Increase.png to ~/Desktop/LC Convocation VUO Master/Image Elements/GUI_Buttons/Zoom Increase.png. (The ~ is an abbreviation for /Users/[your username].)

jstrecker's picture

[Alastair (@usefuldesign)] Could we please change the title of this FR to more accurately indicate what some of us are after with this: a basic Marco in QC terminology node or "Group Node" as Chris (@cwilmsloyalist) called it here.

Changed, rather verbosely. Hope that helps.

[Alastair (@usefuldesign)] Whereas I want three kinds of sub-compositions

Yes, your characterization of Global (current behavior), Local (Ability to create composition-local subcompositions, and Group Nodes / Macros (this feature request) is pretty much what Team Vuo is thinking, too.

[@bLackburst] I just pledged 40 votes to this but the distinction between this and this https://vuo.org/node/1185 isn't perfectly clear to me… We just need qc style macros.

I hope Alastair’s answer makes it more clear. I think you voted for the right one.

Usually with feature requests we try to split them into work that can be done independently. Like here, it would be possible for Vuo to have local subcompositions without grouping or vice versa, if the community had an overwhelming desire for one to be implemented before the other.

[@bLackburst] It might be worth making mention of the fact that macro/group/collapsed nodes should be live-editable

Consider it mentioned. Although we don’t have a public feature request for that, Ability to edit GLSL shader code in Vuo Editor has a similar need. So the ability to live-edit nodes (covering both GLSL and subcompositions) is in our plans.

[Alastair (@usefuldesign)] Nicer would be window in window for all types of sub-compositions in same Editor as I've illustrated above

See also: Open subcomposition in same window as composition.

jstrecker's picture
@jstrecker commented on @Bodysoulspirit's Feature Request, “`Change Items in List` node

Oh, I was thinking the hypothetical Change Item Ranges in List would have a Ranges port that is a list of ranges, like Get Item Ranges from List. Having a singular Range port would not be as complex. Still, you'd have to do a little math to make sure you're feeding in the desired number of replacement items. (The range 2-5 would take 4 items, not 5.)

You can generate a list of positions in a range currently using Make Points along Line. It would be cool if we also had a node to more straightforwardly generate integer sequences.