- This topic has 28 replies, 4 voices, and was last updated 8 years, 9 months ago by
.
-
Posts
-
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.
@ Brian, yeah, the don’t be dumb suggestion is always a good one 🙂
@ Vade, you phrase your opinions in a pretty damn inflammatory way, and you’re still doing so: “is just not a sane way to work, regardless of the percent or two difference the non encapsulated macros get you.”
1) My mind isn’t boggled by the comp; I find it to be simple and I also don’t have any problems editing it on my system.
I provided the full comp before cutting stuff out, mainly because I didn’t for a second think it was going to get this kind of awesomely professional public reaction.
I did provide ample with how to recreate the issue – with Syphon Server toggled on, CPU jumps 100+%. That’s how to recreate it – turn on Syphon.
In the email along w/ the file, I explained the bit about loading some external qtz’s from a folder. I included the main qtz in question, the folder of modules, as well as the actual Xcode project.
2) I gave you quantitative data about the average percentages of difference. If we’re on some kind of non-trust system where I absolutely have to take screencaps….OK.
3) Please. That is so patronizing. I explained to you that with Syphon ON, GL Profiler crashes on my system. Maybe I should have gone the extra step of detail to inform you that GL Profiler works without it ON and when profiling other stuff, but I thought that was implicit in the statement that I’d done profiling earlier, before introducing Syphon.
Profiling in the QC Editor *is* useless, in general, because it has various leaks and bugs. Anyone who makes a point of regularly profiling in the QC Editor is either a naive newb, or an idiot.
Vade: “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.”
I love this part in particular. It’s just a frigging plist dude.
I didn’t report this to be a shit magnet, I reported it to give a head’s up about a potential issue. Whatever floats your boat.
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.
Yeah, it’s absurd.
I’m trying to debug errant behavior in *an application* that also occurs in *the QC editor application* when running a “qtz file” that my app uses as a resource.
QC has additional stuff going on with the Editor and problems leaking with various *stock patches* that don’t leak outside of the QC editor environment, that profiling in QC is pretty much a waste of time when the baseline is going to show a bunch of leaking and foul shit when profiling a frigging two patch composition. What would the best valid test, would be to suggest to run the qtz via the simplest possible program that can run it, not to run it in a program with known bugs and leaks (eg., QC Editor). Yeah, only a naive newb, or “total fucking moron”(as you put it) would be profiling a qtz in Quartz Composer editor.
I explained that pretty clearly, and am at a loss as to your motive or lack of understanding in convoluting that. It doesn’t mean I have ambivalence about profiling, or think profiling is moronic.
If I was to submit a file to Apple, I’m pretty sure they wouldn’t pop on the Apple forum and rip me a new asshole b/c of a matter of opinion , or even fact.
As far as your inflammatory comments go, it’s good to know you have the ear of the QC Gods the have bestowed upon you the supreme knowledge of what they did or didn’t intend.
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!
Here’s my outlook on it at this point.
I came on here and mentioned something I was seeing with performance. I asked “is that something that has popped up before, and/or could it possibly have to do with OpenGL Scene grab.”
Keep in mind, I’ve mentioned bugs about the OpenGL screengrab screwing something with texturing and mesh creator up, with whatever you had going on in previous versions, that my merely mentioning wound up with a solution. If I *did* send a sample, I don’t think I simplified it… I just sent it along in an advanced form, because *sometimes bugs result from non-simplistic combinations*.
With that in mind, I felt like the appropriate *starting point* was to go ahead and send along the project, as well as separating out some of the critical qtz resources. So it uses half a dozen plugins or so, and it didn’t have some non-essential stuff carved out.
If that was too much to handle, I’d tend to expect an email like “please trim some stuff, this is hard to sort through”, not the reaction that happened. I can be pretty snappy sometimes, so I kinda get it, but nowhere has being a know it all ass with knee jerk reactions been ordained cool or a positive characteristic.
Believe it or not, this is a pretty regular starting point for me with a number of these kind of bug scenarios, and I’ve dealt with plenty of people that actually do *not* have problems with files being reduced… because they aren’t overwhelmed easily, and take pride in their work actually working in complex scenarios as well as trivial ones. I’ve worked with other people at private companies that work on QC based tech, or people within Apple on such issues, to resolve bugs. Very often, from the most complex project, with no reduction *at all*, the bug can be sussed out.
At no point does private file exchange result in knee jerk whiney reactions, where privately exchanged files are arbitrarily panned with pretty insulting verbiage, *in public”, when I’m dealing with Apple or other companies or co-workers that I hold in high esteem, or simply know what professionalism is.
Maybe I have an unrealistic expectation of professional decorum. One, you may be entirely wrong in your assessment because you’re only looking at the scenario through your experience and the myopia of your view. Secondly, even if you were actually right, it’s highly untactful and unprofessional.
I’d advise other people who inquire about function and submit any kind of files or source to consider the reaction here. If someone has their panties in a wad, or the composition boggles their mind or simply doesn’t jive with their sense of style, you’re probably letting yourself in for a joyful public airing of that *opinion* instead of more discreet and professional private contact, in the same way that the file was sent (privately). That’s obviously pointed at this particular scenario, but there’s some universal truth in that.
After that kind of treatment, it’s not like give a flying fuck if your plugin works or it doesn’t. In some scenarios, it being turned on flips out CPU consumption. FACT. I’m not really interested in helping one damn iota after the really cheap slamming on your part.
Further, you have to be FUCKING KIDDING ME.
We’re talking about four comp loaders, and a shit ton of some multiplexing, admittedly, but that’s the only thing that someone could go “woah” about, and my experience and testing let me to that. It’s not some design or route I pulled out of my ass on whim. It’s the result of a *actually taking the time* to create a variety of approaches, and one without one lick of the multiplexing stuff you probably took a shit when you saw. I had one iteration of that was much different, and without one lick of multiplexing, and strung some renderers together. It was *not as fast*, using multiple alternative routes. That the Editor in Lion takes a shit when you try to look at it… is sad, but that take was expressed after you deciding it would be really cool to foam at the mouth some, as was the request for other profiling. That anyone would go “ohhhh, it’s a lot of multiplexing, how can you expect Syphon would work!”. REALLLLLLY?
REALLLLLLLLLLLLLY? Sure, that makes a ton of sense.
So, it could take about 5~10 minutes to send you some files, but DO NOT GIVE A FLYING FUCK at this point. I spent a bit today setting up something similar using standard API’s and it worked fine. That seemed like a more productive move for me. Again, if I have the time and the mood strikes me to do some charity work, I’ll give it a look again and push something to git or wherever the hell you host it. Seems more constructive than getting raked over coals for no reason other than some weird sour grapey vibe.
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.
Thanks for the feedback.
To be clear, I didn’t say profiling is for morons; that’s crazy talk.
I made some comment about profiling in editor. When I’ve profiled in Editor and filed bugs in the past, the response was to not profile in editor, because of a number of issues. Profiling in the simplest possible app (commandline preferably) was described as the valid way to peg down bugs. That makes sense to me. I meant something more like “if one has been informed of that, and continues to do otherwise, they are a moron”. If one is not aware of that, like I was not at one time, they are a newb in that area. If that’s an unfair or inflammatory statement, apologies, but I was in a little irritated state after having been told I was an idiot on public forum after sharing files privately.
I really respect your work and am a fan; I enjoy your sense of aesthetics, and am saddened by your public reaction after sharing some files privately.
Yeah, sending you a profile would take a trivial amount of time, but I guess I’m not jumping at the chance at this point.
I also never claimed the issue was common. I came on forum asking if it’s ever come up before or was expected.
Have a good one.
- You must be logged in to reply to this topic.