OF 9.3

[gsautr]

Any chance we'll see an update to this for 9.3? :)

[vade]

Hi @Autr - thanks for your interest. Honestly, the likelihood is slim, only because QC hasn't seen any love in a long time, and is looking rather dead.

I might be curious to see if it just works with the classic legacy OpenGL 1.2/ 2.1 Renderer "immediate mode" renderer, but you won't get any goodies like modern OpenGL Core Profile because QC doesnt support it.

Do you actively use this project?

[gsautr]

Oh, that’s a shame! I’m using VDMX which uses QC quite heavily for VFX - so at the moment I’d like to wrap up my OpenFrameworks sketches into a format that I can use inside there.

I’ve been learning OF for about one month, so only ever version 9.3 and without this addon. I suppose one alternative option would be to Syphon in and out?

[alexdmiller]

@Autr, I'm in the same boat as you—I want "native" support for OpenFrameworks (or Processing) within VDMX. I've used Syphon to achieve this, but it's not the same as being able to drag in a QC composition and manipulate its parameters from within VDMX.

@vade, in the README, you said "The eventual goal is to be able to simply move your existing Open Frameworks ofApp and with a simple re-compile have a functioning Quartz Composer plugin." I know that was probably a long time ago, but any chance you're still considering that?

[vade]

@Autr @alexdmiller :

I hear you - however, there are some nuanced gotchas that make implementing this correctly really tricky that were unforeseen:

• OpenFrameworks not meant to be middleware, meaning, it isn't designed to keep track of OpenGL state nor are add ons or other code in OF in any way shape or form pragmatically or even conceptually aware of how their rendering or logic affects any other part of OpenFrameworks GL, other add ons, or the rest of the world (it has no conception of any other larger world). Quartz Plugins and things along those lines need to ensure they don't corrupt or change OpenGL state for the 'next' plugin or patch to be drawn. This is a nuance totally lost on OpenFrameworks sadly, and a lot of logic, and performance loss is due to that (caching and resetting OpenGL State for example).
• OpenFrameworks has some OpenGL rendering bugs / nuances which conflate the above issue. My solution was / is to keep track and reset all generic state, but the gist is, there are going to be issues none the less and it won't ever work quite as "well" as OpenFrameworks does on its own.
• Processing, OpenFrameworks, Cinder and other creative coding environments are all migrating from immediate mode, legacy OpenGL to modern OpenGL 3, 4 + rendering pipelines. Quartz Composer has no support for that modern GL and is legacy only.

All of those points make it really difficult for me to put time into this project and feel good about it.

I understand the disappointment however. Have either of you tried with 9.3 ? Are there major outstanding bugs? Have you gotten ofxQCPlugin to work ever?

I'd be curious what, if anything is obviously broken.

[alexdmiller]

@vade, thanks for such an in-depth explanation.

I actually don't use OpenFrameworks, and I haven't tried ofxQCPlugin. I found this repository while searching for solutions to my more general problem: I want to use a creative coding environment in conjunction with VJ software (like VDMX).

There are a lot of options available for this, but I've grown dissatisfied with what's out there.

• You can use ISF with VDMX, but I don't want to write code at the shader level of abstraction;
• You can use Quartz Composer or Vuo with VDMX, but I don't want to create compositions at the "drag-and-drop" level of abstraction;
• You can use Syphon to feed in Processing or OpenFrameworks output into VDMX, but then you lose the "native" feel—no sliders for adjusting parameters, no triggering different compositions from within the VDMX interface.

I want to write code at the Processing level of abstraction, and load in the composition as middleware. Now I'm wondering: is the Processing/OF level of abstraction incompatible with the "middleware" concept? (Disclaimer: I don't know anything about OpenGL. Your comment about OF not keeping track of OpenGL state was interesting to me.)

This is pretty tangential to this issue on your repo, sorry.

[vade]

Quickly - I'm on mobile You can totally have VDMX control with its UI the parameters of a processing or open frameworks program with OSC. You can then bind midi or use LFOs in VDMX to control many instances of different sketches or apps like processing open frameworks simultaneously. If suggest checking it out.

Sent from my iPhone

On Jul 9, 2016, at 7:32 PM, Alexander Miller notifications@github.com wrote:

@vade, thanks for such an in-depth explanation.

I actually don't use OpenFrameworks, and I haven't tried ofxQCPlugin. I found this repository while searching for solutions to my more general problem: I want to use a creative coding environment in conjunction with VJ software (like VDMX).

There are a lot of options available for this, but I've grown dissatisfied with what's out there.

You can use ISF with VDMX, but I don't want to write code at the shader level of abstraction;
You can use Quartz Composer or Vuo with VDMX, but I don't want to create compositions at the "drag-and-drop" level of abstraction;
You can use Syphon to feed in Processing or OpenFrameworks output into VDMX, but then you lose the "native" feel—no sliders for adjusting parameters, no triggering different compositions from within the VDMX interface.
I want to write code at the Processing level of abstraction, and load in the composition as middleware. Now I'm wondering: is the Processing/OF level of abstraction incompatible with the "middleware" concept? (Disclaimer: I don't know anything about OpenGL. Your comment about OF not keeping track of OpenGL state was interesting to me.)

This is pretty tangential to this issue on your repo, sorry.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[alexdmiller]

@vade, this is what I've done in the past, but I've grown frustrated with that setup. If you're doing a performance with more than a few Processing sketches at the same time, you have to have them all open, or open and close them manually as you need them. And you have to configure them all to use different Syphon servers. It's just a lot of setup. In contrast, you can easily manage a ton of QC plugins in the same performance.

This is even more tangential, but I also find it tedious to set up OSC to control a Processing sketch. You have to write the OSC listener code on the Processing side, and then manually create sliders to send the OSC messages. To me, the dream would be something like this in Processing:

@Controllable("My Published Parameter")
float myPublishedParameter;

Then I want to drag my Processing sketch into VDMX and see that parameter magically appear in VDMX's "source" panel.

I feel like there's a big void in the VJing space right now: coding something in a Processing/OpenFrameworks environment that can be used as middleware.

[gsautr]

Thanks for the in-depth explanation @vade, and clarity of the problem @alexdmiller

It's a shame Quartz is in so much flux (after the surprise update last year), and understand that OpenFrameworks is not designed to act as middleware, but I've been impressed with ofxGuiExtended so perhaps this is a viable solution;

• QC patch containing one Syphon output, one Syphon input with a VDMX UI textfield naming the Syphon channel (with random str on init)
• Refactor OF patches into FBO classes inside a single OF project
• Loop through available Syphon channels and generate toggleable effects for each w. appropriate controls, outputted back to the Syphon ID
• OF canvas becomes an autoconfigured UI panel for effects used in VDMX

Difficulty here may be to link saved settings inside OF with the unique ID of the Syphon channel from VDMX. You could have a single XML file for all settings, but not sure how you could delete unused settings... which would be an argument for using OSC.

So tangentially (sorry because I'm now typing out-loud), this may be a better alternative solution;

• QC patch containing one Syphon output, one Syphon input with a VDMX UI textfield naming the Syphon channel (with random str on init) - QC patch can also be effect specific - ie. myOfxFilter, myOfxGeometryAdjust etc
• QC patch has all UI elements needed to control the patch
• Refactor OF patches into FBO classes inside a single OF project
• Loop through available Syphon channels and generate individual effects for each - the QC patch sends a string of "effectType" or similar
• OSC communication between the single OF project and QC

Difficulty here is the mass amount of configuration needed. Ideally you could have a single configuration file used by both OF (for reference to OSC urls and port numbers) and QC (for generating VDMX inputs and OSC destinations based on "effectType" flag)... I'm not sure if inputs can be programmatically set in QC though.

[vade]

May I suggest - if there is interest, someone take direct steps to try 9.3 with an immediate mode renderer and provide concrete notes on what does not work?

[alexdmiller]

@Autr, funny, I was day dreaming about a similar scheme to the one you outlined, but for Processing. I think it might be a really viable solution.

@vade, yes, I'll do that sometime this week and get back to you.