Forum Replies Created
-
Posts
-
Ah. Thanks for following up. We can fix that by cleaning up the file path before saving. Good to find little things like this.
./model.extension
if the QTZ and model.extension are in the same folder.
./relative/path/to/model.extension
with the QTZ being in the folder above “relative”
You should be able to make an ofTexture yourself and manually set the pixels, removing a copy phase.
There is a lot to respond to here.
The earlier screen grab bug was helped fixed by Tamas Nagy, who reported a similar bug, but with a simplified use case and I fixed it.
> *sometimes bugs result from non-simplistic combinations*.
I totally agree. I’ve said this line to other companies before, to C74, etc. However, there is some truth that simplifying your use cases to isolate a bug, many times, exposes a) the bug in simplified form, and b) issues in your own patch you did not know about. I am not claiming these as universal truths, but in my experience its held true almost all of the time.
Its not just the multiplexers George, Its the fact that there are a ton of modules included to be looked at, and possibly trigger the bug. I could not reproduce it, therefore simply turning on Syphon *does not* give me any information (other that it works as intended here – and doesn’t there),- I documented and recorded in two screen grabs. Your profiling is simply reporting symptoms, not much usable data. CPU increasing by x is not much of a “profile”.
Again, a simple sampling with a profiling app like shark, or instruments, & more information about what module is loaded, GPU specs (perhaps I cannot reproduce due to my system?) would have been helpful. In the time it took you to write that reply, we could have information to go on. Its literally about 2 seconds of work. Seriously. Run QC. Turn on Syphon (which seems to be all it takes to trigger it). Click record in instruments. let it run for 2 seconds. Click Stop. Send us the info.
I’m over it. Glad you found a suitable work around. If this CPU issue is as common as you claim, I’m sure we will see other reports.
Charity, Pride. Ill let those go.
Look, ill be totally honest. And i’ll air this publicly, I think its fine, At the end of the day, you just rub me the wrong way. Thats on me. Most of this reaction to you is due to the compounded readings of your interactions online and our other communications over the years. Its hard for me to point to anything specific, and its probably irrational, multiplied exponentially due to our vastly different personalities and approaches – but at the end of the day, for whatever reason, I respond to you differently than others. There it is.
Maybe you can take some satisfaction from that. You’re clearly smart and talented. But my god do you get under my skin. Take that as a compliment. I can admit thats (mostly) on me – at least my reactions to you.
I’ll publicly apologize for shitting all over your QC comp style, but when you tell me profiling is for morons, I don’t know if I can forgive that : That tells me you are more interested in pointing out the issue than solving it.
Good luck.
DJ Rich, you need to ensure you install the Syphon Quartz Composer Plugin as well. Check the downloads area and follow the instructions in the read me. Arkaos Grand VJ and Media Master have native Syphon server support, but not client (for now, perhaps?)
http://www.arkaos.net/blog/2011/11/tips/syphon-mediamaster-grandvj/
George. This is simple. Some method or function is using CPU when the plugin is enabled. A CPU Profile will show you what the fuck is using the CPU usage. HOW DO YOU THINK THAT WONT BE USEFUL? I DONT GIVE A FUCK ABOUT THE EDITOR’S QUIRKS OR MEMORY LEAKS – WE ARENT DEBUGGING THAT. THAT INSTRUMENT WONT EVEN SHOW YOU THAT INFORMATION. The instrument doest give two tugs of a dead dogs cock about that. Nor do I.
I just. Want. Data. About. This. Issue. That. I. Cannot. Recreate. Here. With. All. Of. The. Information. You. Have. Given Me.
You claim to have errant CPU usage due to our plugin. Thats fine! We beg for a profile so we can see what is using CPU usage. Thats absurd!
I’m sorry, this is fucking absurd. If you are attempting to debug errant behavior in an application (namely, 100+% CPU increase that you can trigger by enabling a plugin), and then claim to say that profiling said application is useless, that tells me you have *absolutely no interest in actually solving the problem*.
Think about that for a moment. Really, really think about why running shark, or instruments while Syphon is on, using this extra CPU usage for whatever reason, would be something only a naive newb, or an idiot do. Meanwhile, you can speculate up the ass as to what is causing the issue. Clearly the fucking stack trace, methods, or any additional information is only something a total fucking moron would want. How on earth would that help solve the problem at hand?
Then get back to me with the Time Profiler usage sorted by stack trace in instruments, so we can figure out what the fuck is going on.
As for your other comments, if you were to submit a bug report to Apple, or to Cycling 74, do you really think they would be ok with the provided information? C’mon.
Additionally, I stand by my inflammatory comments.
Hey Normen, one idea Tom and I were discussing, was the possibility of setting up a “Syphon IO” application, where we could provide a plugin interface for things like QTKit Capture, and for IP Cameras (and additionally, native Deck Link, etc capture, screen capture, etc).
I think this could either be great, or a pain in the ass. Thoughts? Is that something you would be open to having your code included in, as a plugin? Let us know.
Uhm. What? Your project required at least 5 or 6 Kineme plugins. Those are external dependencies. What mystical way? I was referring to workflow and ease of debugging, and the fact that, in my mind, a debugging a comp like that (let alone making one like that) is just not a sane way to work, regardless of the percent or two difference the non encapsulated macros get you.
My reaction to the composition was simply that it is highly complex, and that debugging large “non functionally” encapsulated patchers (in any environment) is very difficult. Simply following along with the program flow and ensuring there are not programmatic/logical issues (which lead to assumptions about state, and thus about the bugs, which may be wrong) or legitimate errors due to those bugs. Additionally, with the comp provided, there were no instructions to re-create the issue at all.
We asked you supply common information asked of anyone, ever, who debugs things:
1) Provide, if possible, a simplified reproduction case.
You provided us with a complex case and no instructions on how to re-create the issue.2) We asked for quantitative data.
You provided us with a statement that Syphon uses more CPU when active in your comp, in both the editor and your app.3) We tried to guide your profiling, and suggest a few methods.
You claimed editor profiling was useless, and then can’t get GL Profiler to work (granted, it can be finicky, but myself and many others have not had issues with it and Syphon).Look, we want to find bugs. No one is saying there aren’t incompatibilities, there have been in the past and we’ve fixed them. We’ve never run into this (at least not in the configuration you claim to be using).
Just let us know.
Ok, so. I got the comp up. If I don’t move around the editor (that uses 100+% CPU just navigating the comp), and run the viewer (once I had the plugins in place), I got the following CPU with Syphon off and on:
Basically, 25% CPU. I suspect you have a module that triggers specific behavior or something out of whack with an old plugin version. FWIW, I saw no OpenGL errors of software fallback.
Let me know if you can narrow this down.
Normen, do you have a google code account? If so, I can add you as a committer to the Syphon-Implementations project, and we can host it there (if you want to) 🙂
Dude, if QC editor on a modern machine can’t even draw the comp correctly (the QC editor, when viewing and trying to *look* at the comp, is all but non-responsive). I don’t even know how you could make that comp. Unless something is so fucked in me opening it, or the comp is corrupted…
After spending a few moments looking at that comp, I am going to go out on a limb just frankly say, that is totally not how QC is intended to be used. My brain hurts that anyone would even make a comp like that, and then complain about odd behavior.
Sorry to sound like an ass, but, I just cannot express in words just how much that explains to me.
In other words, uh, yea, can you simplify that?
For what its worth, I’ve never had issues with GL Profiler and Syphon in any App (it just works), and nor have we gotten any reports about high CPU usage due to Syphon at all, under any circumstances. This is either an edge case, or something in really wonky.
Just Run GL profiler, break on software fallback. That takes 30 seconds and run it on the comp exhibiting the behavior. Also, check statistics, and see what GL calls are taking the most time.
Is this a fully custom app, or a Quartz Builder app? – Ah, happens in QC. Just.. send us the QC comp if you can’t simplify it… ?
Also, are you initiating you GL context on one GPU, and displaying on a second GPU? (i.e., running a second application that is on a second GPU, listening to the server?).
You can additionally use GL profiler and enable break on SW Fallback, to see if any GL calls happening are not being run in full vertex and fragment acceleration (each can be individually done on the GPU while the other is accelerated).
Normen, this is great work! Do you intend to open source these? If so, we are happy to host in the main repositories. I have some additional code to get native driver input from Black Magic Devices (which is *seriously* faster than native QTKit and Quicktime Library 32 bit calls).
Either way, and whatever you wish, the Net camera inputs are huge.
Thank you for helping the community.
Can you post some more information please? Thats not enough to go on. Are you using an example? Are you using custom code?
