jstrecker's picture

Jaymie (@jstrecker)


  • Vuo Founder
  • Team Vuo
jstrecker's picture
Jaymie commented on Bodysoulspirit's Feature Request, “Code sign and notarize exported apps

I realize I would need join the Apple Developer Program to distribute this under at a cost of $99US/year. Would there be any other expenses and fees I'm not aware of?

If selling your app, an additional cost would be the 30% cut that Apple takes (or 15% for approved small businesses). Besides that, there's sales tax / VAT, business registration fees, accountant fees, etc.

To get through the app submission process, you'd either need to put in significant time toward understanding it and going through it with command-line tools, or you'd need to hire a developer (such as Team Vuo) to walk you through it.

There would also be the cost of your own time for getting through Apple's review process and updating the app from time to time as required by Apple.

The message I get when exporting an App that it "requires macOS on an Intel (X86-64) CPU",

With the latest version of Vuo, you should only see that message if your composition contains nodes that aren't compatible with Apple Silicon, specifically Leap or NDI nodes. If you see it in any other case, I'd appreciate if you could create a bug report so we can figure out what's going on. Normally, the apps exported by Vuo 2.3.0+ are "universal" in Apple's parlance, meaning that they contain both Intel and ARM binaries so can run on either.

jstrecker's picture
Jaymie commented on Jaymie's Discussion, “Plan for cross-platform support

funwithstuff, thanks for pointing out iOS, since I hadn't mentioned it. Here's our team's thinking on that…

Our ballpark estimate is that the time needed to implement deploy-to-iOS would lie somewhere between deploy-to-Linux and deploy-to-Windows. iOS is a close relative to macOS in some respects (Apple frameworks for things like video and multithreading), while Linux is closer to macOS in others (user interface paradigms, device support).

Besides that, the other main difference is that iOS has stricter requirements than macOS for the apps that it allows to run, and what those apps are allowed to do. In order to distribute any iOS app, you have to purchase a $99 USD/year Apple Developer membership. The process of getting an app to run on a device — whether you're distributing it through the App Store or running it on a predefined set of devices — is quite complicated even for seasoned developers. We could potentially automate parts of it and provide instructions for the rest, with the understanding that it would require continual support and maintenance, since sometimes Apple makes changes to the process and sometimes there are bugs you have to work around.

We're still thinking it would be best to implement deploy-to-Linux first, not least because it would make it possible to run Vuo compositions on hardware other than Apple's. When we reassess after deploy-to-Linux is complete, we'll take another look at deploy-to-iOS and see how it compares to the other possible next steps at that point (deploy compositions to Windows, edit compositions on Linux, …).

jstrecker's picture
Jaymie commented on Holo's Discussion, “draw with a kinect

It was Joe's idea to use the Leap Motion, but yeah, I agree it provides better control than the Kinect for drawing. Here's a modified version of the Draw in Space composition for Leap.

jstrecker's picture

I've tested this in multiple screen layouts and it appears that X behaves as I would expect and gives a consistent value no matter which screen is currently active however the Y mouse value seems to be calculated using which ever screen is currently active.

Good debugging work. Yes, you're correct. Receive Mouse Moves should output the same coordinates regardless of which screen the active window is on. This works for the X coordinate, but the Y coordinate is off. The problem happens when Vuo flips the Y coordinate so that 0 is at the top of the screen. It mistakenly bases the flipping calculation on the height of the currently-focused screen instead of the screen at (0,0). We're working on a fix.

jstrecker's picture

That's pretty much how the system reports it. On my MacBook Pro screen, which is also 900 points high, the Y-coordinates that macOS reports range from 0.02 (bottom) to 900 (top). The only change that Vuo makes is to flip them vertically, so they range from 0 (top) to 899.8 (bottom).