Forum Replies Created
-
Posts
-
Can you both (Echoplex / ultraviolet) please expand on your questions. I am unsure what either of you mean. Its hard to understand what you are asking.
That ought to work just fine. Did you download the DMG from v002.info ? It decompressed, verified and opened ok? I’ve used the 8600 GT with those models with the Rutt (a friend has one), so im pretty sure it works.
You can try the beta of version 3.0 at:
http://v002.info/downloads/beta/ (its just the plugin, and that plugin is actually unique, you can have both 2.0 and 3.0 installed, and they both show up “uniquely”, so the search the path library and try to find v002 Rutt Etra 3.0.
Thanks, curious the issue is.
That is exactly how I had to manage it bangnoise, via an RII patch. I also could not figure out how to send the entire output of Grand VJ into an effect. This *greatly* limits how Syphon can work with it.
You can of course use a Syphon Client as a QTZ “source” to trigger. That works as expected.
In my playing with Grand VJ, it strikes me that they would either have to add Syphon to Grand VJ natively so it grabs the full mixed output, or re-do the effects architecture to make it work in any way that users would reasonably expect a Syphon *output* to work.
Does that clear it up, even if it is somewhat less that helpful? I would petition or ask the Arkaos folks about it.
If you have 2.6.2, and enable Syphon output in Modul8, you ought to be able to open the example client composition when you have installed the Syphon plugin for Quartz Composer, it ought to just work.
If you use the example composition, it uses Syphon Server Directory to find available servers and output a structure, which is then filtered to find the keys for the first server, and is sent to the Syphon Client.
I actually don’t have 2.6.2 at all, so I cannot test this myself, personally. I will try and get my hands on the beta, and verify the procedure. I know it works though, as people have already done it.
I have looked a the GEM source code and think it would be pretty straightforward. Like most things, its a matter of time and priority.
Of course, that GEM external would be Mac OS X only.
Hi Lau,
If you *really* want to record > 1 streams, just duplicate the application and run more than one instance. Hope you have a decent disk 🙂
Ah, that makes sense, I guess. Thanks Brian. I thought you could, maybe, I dunno, do direct GL calls or something. Alas!
If you make a new texture, you should not be using glReadPixels, use glCopyTexSubImage2D, which is hardware accelerated and grabs from the current specified glReadBuffer, and copies the screen (or, well, whatever buffer you specify) into the currently bound texture.
That should be plenty fast.
Nice! glad you are finding Unity + Syphon useable and useful 🙂
Brian Chasalow has committed some newer Unity 3D scripts and plugin to SVN. Are you using the public beta 2, or SVN versions of Syphon?
I mention because the new scripts Brian worked on have a slightly different rendering method, and I believe he has fixed some bugs with the Unity implementation.
In theory though, you ought to be able to get a texture reference from your post process pass, and send that to Syphon. I think that ought to be possible with Brians SVN version.
This is *probably* a notification delay in NSDisttributedNotification. Basically clients and servers post notifications to the operating system, which in turn notifies the app that a server, or a client has appeared and requests a list of available resources.
I dont know what the normal delay is in the client finding a server. That is a good question. You need *immediate* response?
You could try making a call to [SyphonServerDirectory sharedDirectory] on level load, and keep a reference to it (so the singleton object is already initted in your app), and only call [serversArray count] every frame. You might be seeing the startup cost of initially making the first and only instance of the singleton. Try making the singleton prior to your first frame being called?
That might help shave some time off. that said, NSDistributedNotification is not amazingly speedy, and object creation is *very* optimized, so id be surprised if creating the singleton SharedDirectory prior to level load made a giant difference.
Hey Johnny,
The only thing I can think of, without looking at a specific patch, is that jit.gl.model might be expecting normalized, 0-1, texture 2D coordinates, and Syphon outputs a rectangular, non normalized texture (a necessity due to the way the internal API we are piggy backing works).
Can you send over a patch, so I can take a peek at it?
Well, there is definitely something odd going on, but I am having a hard time locating exactly where it is.
With clients and servers in the default help file, using @servername attributes I can resize all day. The clients and servers are in different patches, with different GL contexts, using different windows to draw to.
If change your patch to do a similar thing, have clients and servers in the same patch, but different GL contexts, I can re-size the client context and its fine, but the instant I touch the server context, the client objects need to be re-initalized.
Curious.
Thanks for the bug report. I can confirm something odd is going on. I think this is an issue where a few subtle things are going on.
1) Timing is not clear when using the automatic drawing inherited from OB3D, we suggest using @automatic 0 – but thats not all
2) it looks like resizing a window is actually doing some weird GL stuff, and we may have an “init” issue because of that.
Stay tuned, and thanks again.
The upcoming release of eMotion has Syphon support integrated into the app. Ill link to ascreencasts up once Adrian has them online.
🙂
I *think* if you install Soundflower/Jack or one of those Audio Drivers that let you send audio dynamically through the system, you can get more controls (and maybe even get a specific application).
Try it out, let us know.
So, for example, using the QC Syphon server plugin, you could publish from QC, and record in our recorder.
Or you could publish in Processing, and record in our recorder. Or Jitter. Or Unity. Or Open Frameworks (get the idea? 🙂
Same goes the other way around. Any of those can leverage Screen Capture as a “source”.
Any new implementation adds a whole new factorial’s worth of combinations. Its going to get fun.
Read the docs. Don’t be lazy. 🙂
Any application that uses Syphon uses a Syphon Server, internally. That is the “object” that Syphon sends with. Anything “broadcasting” with Syphon is a “server” , anything receiving Syphon is a “Client”
Thus, the Screen Capture app is a Server.
The Recorder is a Client.Any app that can read from a Syphon source (ie: a Syphon “Client”) can use the Screen Capture as a source.
Any app that can publish frames to a Syphon client (ie, a “Server”) can have its output recorded via Syphon Recorder.
You will only need those 2.
Syphon has a Recording app we are beta testing. It records high quality video from any Syphon Server.
Syphon has a Screen Capture app, which is a Screen Capture program that publishes content as a client, so any Syphon Server can grab what it sees on screen, useful for applications that are not, themselves, Syphon enabled.
The Syphon Screencapture app is in SVN, so you would have to compile it yourself (pretty straightforward), and you can look at the other forum thread for the latest release of the Syphon Recorder movie recording app.
Those 2 let any Syphon app record, and let you input to Syphon from your desktop.
Sorry guys, I was away the weekend. I will try and get to it today. I am thinking it may make sense to do without the SyphonImage, and simply have latestFrameImage return a texture ID which can be bound. The additional complexity of emmiting a jobject (the JNI’d version of the Syphon Image) that is temporary, seems kind of of limited use.
Thoughts?
