Network transmition

imagenero's picture

HI, I have two composition that talk to each other using the network broadcaster and reciver.The broadcaster is set to "UDP Broadcast". I found that when i run the comps without some kind of network or internet (wireless or ethernet) the comunication does not happen. I notice that ifI have QC running and i catch a wireless network for just an instant the commuication betweeb comps starts. This becomes a problem because sometimes i have to use my comps where there is not wireles or cable network...then i cant use my comps. Does someone knows what is going on and a possible solution? My comps run in the same machine so there should not be any need of a network with other computer... Thks.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

cybero's picture
Re: Network transmition

Hola, Imaginero

The answer's within your recorded and posted observations.

User Datagram Protocol [ UDP ] is an internet working protocol stack that requires the existence of sender and receiver machines at two distinct IP [ wireless or wired ] addresses. so when you connect you connected your machines within their own network or over a far wider network , a UDP session could be initiated and typically, media and feedback information strings then transferred from one machine to another, such as rendering QC file.

:-)

edit - so when you are running an existing ethernet connection and possibly open up your own Airport connection, you might unwittingly initiate the UDP negotiation and if this is happening briefly then the UDP is briefly starting up until you drop your newly made IP address connection.

Apologies if I've misled if there is some undiscovered country for UDP negotiation implicit in the UDP patches behaviour [I'd like to think so] , but I think otherwise that explains it for you.

imagenero's picture
Re: Network transmition

So If i understand correctly... when i have two Quartz comps (running in the same machine) that communicate between them using UDP...This machine needs to initiate a session with another IP (via internet or local) to start the UDP protocol on my machine so that the Comps can start communicating, otherwise..(as has happend) the machine won´t allow the Comps to communicate due the lack of a triggered UDP session... is this so?. Backstory: I have two comps because one is the mixer control with midi (i use the view from this comp as Graphic interface) and another comp that delivers the output (i use this view as the output of the mixer). The question now would be: can I communicate the two comps without any UDP session initiated or how can initate a UDP session without an internet or local network?

Thanks for the time

dust's picture
Re: Network transmition

interesting.... i think OSC is the way to go for your controlling. i know it is inherently a udp protocol as well but without some hackery i think it negates the tcp protocol so that on a local loop back 127.0.0.1 or base address 0.0.0.0 it will work without the lack of a network connection actually it should work without a ethernet card all together. another possibilities is to use global midi control messages. so you could make a midi gate with kineme midi. i think those two options are your best bet if you are just trying to control something. i think the net send receive will work better if your needs are to be syncing views or something but if you just want to send some numbers osc or midi works fine actually osc sends boolean so you can send on off enables to start things as well.

something i like to do when i don't have a network but lets say want to use my ipod to control something i use an adhock network so you could try to use the broadcaster and see if this wil solve your problem as well. to create an adhock network go to your airport icon in the menu bar then go to create network this may fool the computer into a udp tcp session. this way if your at a gig or something and they don't have a network at least you can have local network via adhock. if you want to bridge that network to the WAN you can either make a proxy or go to sys prefs sharing and set your bluetooth firewire usb ethernet etc... as a network to share. so lets say you don't have a router but want to get your ipod on the internet this is what you would want to be doing. or lets say your in the airport and you had to buy some net time but you want your friend to get on the net without having to buy more air time.

gtoledo3's picture
Re: Network transmition

I think Dusty has a good point about the OSC. That would likely be my starting point.

Also, Spooky patch for inter-composition communication? I don't think that's an advised use though.

I would be "careful" and not try to do anything too crazy or weird... I know that's a fine line.

This may sound like a cop-out, but do you really have to have the thing that controls the one qtz be a GUI that's a qtz viewer window? If you are doing dual screen, you can just as easily make yourself all of your published parameters, set yourself minimums and maximums, and have a nice slider based interface to control the composition with on one screen, and have the Viewer fullscreen in the second.

I guess I can't envision a scenario where I would want a Quartz Composer based gui controlling another composition, unless it was actually a multiple window QC thing bundled up as it's own app, especially considering the overhead it has to be adding the the scenario. I guess my thought is, why bother with the nicety of a GUI if you are still going to have the editor in the mix? That said, I'm way into QC based GUI stuff as a form of controlling what's in the viewer window...

I'm not 100% convinced about using current stuff like the midi, the OSC, the network broadcaster, spooky, etc., in professional applications unless's being done is really trivial, or it's been extremely well vetted.

It seems like in some of those scenarios, that by the time the renderer is looking for the next round of info, a crapload of osc or whatever might have been sent, and then QC starts chugging along trying to catch up instead of the provider patches waiting and firing only when the consumer asks it to. I'm not totally sure if that's exactly what happens, but it sure seems like it in some cases. All I know is that it can make QC "take a *&%$#".

As far as the Network patch goes, it does seem pretty normal that it would need a network to work, whether or not you are running both on the same computer :) So, the thing about not needing a network because you are running comps on the same computer doesn't quite ... compute. I don't think the patch was written for what you are doing, so it's cool that it works at all really. Surprising even!

cybero's picture
Re: Network transmition

dust wrote:

i know it is inherently a udp protocol as well but without some hackery i think it negates the tcp protocol so that on a local loop back 127.0.0.1 or base address 0.0.0.0 it will work without the lack of a network connection.

Quite right to say ad hoc UDP functionality can be achieved by setting, as you've explained elsewhere before now, [if I recall correctly], loop back and base addresses.

However, unless I've much misunderstood how the Network Receiver / Broadcaster , etc patches are working, I don't think they automatically negate any TCP action whilst UDP is operational upon the same port that UDP is working upon.

UDP does not actually negate TCP/IP, it can as you say, work upon local loop and base address,[ as well as private and public network network addresses ]. VOIP, network games and streaming media usually use UDP, even though TCP is inherently more structured and reliable.

dust's picture
Re: Network transmition

im not sure if you are familiar with quartonian mixer but its an older vj app made with qc. his solution to the controller thing is to actually have the controls is to use one composition. let me explain you have your priview clips etc on the right side of the screen and the main view on the left side of one viwer window. if you make them the right size with two monitors you can align one monitor to the left side of your main monitor then when you stretch the viewer it will stretch across both screens giving you both controls and viewer inside one qc view but spanned across two compositions. in contrary to george i think its actually a good idea to have two comps one for control gui and the other for ouput your just going to run into trouble when you try to actually make it an application. trust me people have been trying to find a professional way to not just forward events from your nibs but to send data between comps without osc etc.. im sure there is a way to make an app controller and save your control messages into a variable then call that variable from another comp but i think there will be some sort of latency. you should look at the quartz composer visualizer application that can do what you are trying to do as well. you need two comps to make it work and it can send the visual data to multiple monitors etc......

gtoledo3's picture
Re: Network transmition

The quartonian setup does make sense, because it's happening all in one environment.

I definitely think that QC based controls are cool, but ultimately, I believe that the only way to ever expect things to evaluate sanely is for everything to happen in the context of one composition, or in an App setting that is designed to make sure that the events happening in the GUI rendering/qtz portion line up with what's happening in the Content rendering/qtz screen.

I don't think that Quartz Composer is designed to truly handle intercomposition stuff that well, if it was much of a consideration at all. I would venture to say that anyone who has done this via osc or the network broadcaster/reciever has seen some crashes along the line.

I'm not downing on the idea totally either, I'm just saying that's a good idea to give it a really rigorous test, and also to honestly question if it's really needed, or just a performance hog.

I'm not talking about anything I haven't tried, that's for sure :)

leegrosbauer's picture
Re: Network transmition

gtoledo3 wrote:
... Also, Spooky patch for inter-composition communication? I don't think that's an advised use though ...

I've seen this 'inter-composition' Spooky Send/Receive patch capability referenced a few times recently but some important qualifying information always seems to be missing in those recent references: It's necessary for the multiple compositions to be hosted together in a single application. For instance, an example of such a composition hosting application would be VDMX. In such a circumstance, the actual compositions would be inserted into the application for usage by that application.

To the best of my knowledge and experience, Spooky Send/Receive won't work if the multiple compositions are simply on your desktop or elsewhere other than together in the same application. I'll stand corrected, if I'm wrong.

gtoledo3's picture
Re: Network transmition

Well, QC is a single app. It definitely does work with two comps in QC. I was just saying I wouldn't advise getting in really deep with it, or doing anything that got really taxing.

To wit, open up Untitled 2, then open up Untitled 3. The audio signal from Untitled 2 feeds over to the sphere diameter on Untitled 3.

Again, I think that the order of execution could possibly get screwy in certain more complex scenarios. Hey, if it works it works :) I'm certainly not suggesting not to do something if it doesn't work.

PreviewAttachmentSize
untitled folder 2.zip3.04 KB

leegrosbauer's picture
Re: Network transmition

I see it! I stand corrected regarding the desktop. Thanks. But I still think that a single hosting app is a requirement. I couldn't get Untitled3 to work when it alone was put into another application but it does work if Untitled2 is put in the same application with it. So ... then is Quartz Composer on two different machines a single application circumstance or a multiple application circumstance? I don't know the answer.

Regarding Spooky Send/Receive getting screwy in more complex scenarios? Yes indeed it can. I'll agree and attest to it. It can crash the hosting app.

dust's picture
Re: Network transmition

thats just spooky you can send images as well. to get gt's example to work you might want scale the range of the audio input in order to see the sphere.

leegrosbauer's picture
Re: Network transmition

See my edit above, dust. They both need to be in the same app. You guys both have an app to test this on. Stick one in the effects folder alone and try it. Then put them both there. You'll see. While you're observing, be sure to consider the potential for fun and games with Spooky feedback in that particular location. ;-)

cwright's picture
Re: Network transmition

leegrosbauer wrote:
So ... then is Quartz Composer on two different machines a single application circumstance or a multiple application circumstance? I don't know the answer

QC on any given machine is a single instance (in Operating System lingo, this is called a "Process"). If you have 2 machines, each running QC, there are 2 QC Processes - one on each Mac. Safari is another process, as is Finder, Mail, etc.

Spooky works only within the same Process -- so, it's confined to a single machine, and a single application on said machine.

So as long as any given app is hosting both compositions simultaneously, they'll be able to share data/values without needing network access.

gtoledo3's picture
Re: Network transmition

Oh, I see what you mean, I thought you were saying that QC didn't constitute a single app environment, and that it didn't work in QC (or is that what you mean by "desktop"?).

I don't think this method would work across two machines... I think the original poster was saying that he was wanting to run from one comp to another, all on one machine. The network patch would be the thing for the two machine scenario.

In scenarios like this one qtz doesn't really take into account the evaluation timing of the other, so if a renderer on one goes calling for an image or value that relies on something being provided by another qtz, the other qtz is ultimately running without regard to the first qtz. so it may not provide it. The provider also might be pumping out values on the "dud" renderer faster than the render chain in the receiver can deal with it. This goes for Spooky, or OSC.

Also, just because communication can be done within another app like VDMX or whatever, using the OSC patch, or Spooky, doesn't mean that app is doing anything to mitigate funkiness, as you well attest to. (The same thing I setup with Spooky can be done with the stock OSC on straight default, btw).

gtoledo3's picture
Re: Network transmition

...Or adjust your default system input :)

leegrosbauer's picture
Re: Network transmition

Frankly, I shot off my mouth before considering that multiple compositions on the desktop were indeed nonetheless opening in Quartz Composer, a single application. I should know better.

We agree, George. I merely made the initial comment because a couple of times recently Spooky has been referred to as if it could perform like OSC. But it's different in respect to the limitations being discussed here. Thanks to Chris for clarifying the exact circumstances and terminology.

heh. Until recently, the only place I 'used' quartz compositions with and without Spooky patches was in a separate application. That said, I used Spooky patches a lot. That's also why I felt competent to attempt to address the single application (now understood as Process) requirement.

gtoledo3's picture
Re: Network transmition

I would have never checked the Spooky out if it wasn't for you talking about it :) It's actually fairly wild and pretty cool. I see what you mean about stressing the difference between the Spooky and the OSC.

Stability becomes such a big deal in performance scenarios, in my opinion, to the point where it is totally paramount. If something malfunctions in unpredictable ways it's basically unusable no matter how cool the function is. I find that "in composition" malfunctions are usually really repeatable, but that "inter composition" malfunctions can be caused by a variety of factors... even things like having another app open that does some kind of process at a crucial time and screws things up, errors and crashes are usually are more aberrant, and can even tie into things like handling the editor surface, or triggering a "tooltip" when hovering over a port.

I'll be the first to say that sometimes stability or performance aren't concerns at all, but in my world, that's usually only if it's a total offline render thing, or something informal and between friends, like some Cam Twist action :)

leegrosbauer's picture
Re: Network transmition

Again we agree.

I'll clarify that my usage of Spooky patches, while frequent, has also been observational in nature, therefor I didn't care if I crashed the app. It was merely being used as a sketch pad at that juncture. As I hinted below in my edited comments to dust and to yourself, Spooky patches can create some interesting inter-compositional feedback. I use Spooky image filters. (I posted them in here once but now I can't find them again. pfffft). I move the Spooky filters around in a multi-compositional effects chain and if I see something cool, I then try to recreate the whole chain as a single composition, sans the Spooky patches.

I'll keep looking for those Spooky image filters .. or I'll repost, if anybody calls for them.

dust's picture
Re: Network transmition

so i decided to give it a try use one comp for controls and the other for viewing. so far i have not run into any problems with spooky but then again im only using one send and that is to send the main program out. here is a quick video tutorial of how these patches are working on my end. they need k3d and the toggle plugin (sometimes im to lazy to make a java script toggle) just search kineme for toggle if you don't have it. im using one of the slider examples not sure if i picked the best one or not but wanted to try spooky. later i will try and see if 2 quartz builder apps will honor the spookiness. basically this has a contextual menu for audio devices and two sliders. one is a crossfader the other blends in some noise. have a watch of the quick video and try the source out you might find these spooky patches interesting i don't know. basically i did a mini vdmx sort of. in vdmx i like to add lets say a sound source to a slider so thats what this does for me.

http://d0cut0uch.no-ip.info/dvjx3d.mov

check the pic see if it interests you or watch the movie. just throw your own models in or replace with k3d stuff with video stuff or whatever. this is just a proof of concept on how to use 2 comps i guess.

(edit) oh yeah the music is a composition of mine as well, i might make a video for it with this composition, if you watched the movie do you think it looks cool ? ill obviously be triggering more than 4 models maybe 16 of them.

PreviewAttachmentSize
Picture 1.png
Picture 1.png431.1 KB
dcontrol.qtz49.12 KB
dview.qtz6.35 KB

leegrosbauer's picture
Re: Network transmition

Movie looks cool and the usage circumstances look correct too. One instance of Quartz Composer, a single Process, hosting two compositions. Two QuartzBuilder applications? I dunno. I suspect that's two Processes and therefor not viable. If it's only one Process I would inquire for clarification on why this is so.

imagenero's picture
Re: Network transmition

Hi there.

You guys are way ahead of me..I just tried creating an Adhoc network (as mention) and it did work. The two compos with network broadcaster-reciever comunicated without internet or local. So for my next gig I am clear. Thanks a lot. I will check out the spooky control video to see its workings. FYI, what I have is one comp with three channels preview, image FX visual feedback (hue, sat, size, rate..etc) switcher info (channel out, loading channel, etc), and a second comp with the three channels layered on full screen for the second monitor. Everything is controlled by a Korg Midi controller. its the first comps i made for live video editing so i am sure its very clumsy programming, but is the one I use for show. Now i a m working on the new one that is an app so no need for inter composition communications... just Interface builder and one comp. Thanks again.

dust's picture
Re: Network transmition

glad the adhock worked i was thinking that might trick the broadcaster. so yeah thats cool a 3 channel piece. i have done a few 2 channel pieces for some college classes but generally like to keep everything one channel. you can do some cool multi channel effects though. if you composite right you should be able to bring elements or video elements from channel one to channel 2 no problem. actually haven't done any green screening in qc but that might be something to try today ? im thinking i would do the key in another program and use the alpha to mask or something not sure. got me thinking though. don't worry about people being ahead of you in qc i just stumbled across it last year when i was doing some multi touch and feel in love with it. its such a deep program there will always be something over my head for sure. just wait till SL comes out.

gtoledo3's picture
Re: Network transmition

Two QB apps are definitely two processes... they make separate plists, have separate running environments, etc.

It seems like inter-composition stuff has been talked about hand in hand with Spooky and OSC for a really long time, so the proof of theory aspects have been well fleshed out. There are some cool GUI element examples at the old quartzcompositions.com as well, though they are stark in some cases, and really just starting points.

"Loops" where a consumer from qtz A needs info from qtz B, which in turn is calling upon info from A, is especially when things get really hairy, and into really bad idea zone.

I am really excited about the future of qtz based GUI stuff though, and I think it's excellent for doing little drag and drop things where you can see previews of media, and then make performance queues by moving the items around.

leegrosbauer's picture
Re: Network transmition

Well now, and "Loops" seems to be just the thing that I find so valuable, doesn't it? Ok. Got the picture. You would like to shut down discussion of that usage, right? All well fleshed out and whatnot. k. Understood.

I'll make you a deal. I'll clam up about that particular aspect, even though it's far too valuable of an observational tool for me to abandon simply because it might toss a damper on somebody or other's live performance aspirations.

In exchange for my silence on that subject I propose that we attempt, at least occasionally, to broadening our discussions of composition usage from being almost entirely restricted to the perspective of a single composition, running solely in Quartz Composer, serving solely aspiring performance artists who mostly only seem to be interested in movie clips of the comps to slice and dice anyway. Me? I'd like to see us talk about broader usages of the compositions and broader presentation techniques.

That seem reasonable enough to you? How about let's talk about actually running these comps in something, once in a while. Because you know .. the real movie special effect people have us QC guys all beat by a long shot when it comes to assembling cool looking imagery. We shouldn't even be trying to mix output with those particular technicians, imho. We can't do jack with QC, by comparison.

gtoledo3's picture
Re: Network transmition

I think that the only way to gain new "solid" function is to flesh out the circumstances under which it can malfunction, and why. I have no desire to stymy discussion on this; I wouldn't reply. I guess my meta-communication is off.

I'm interested in it, so I'm fleshing out reasons why it can go bad. I would really hope that you don't clam up on it... it's only by us being vocal about the way that we like to use things, and the kind of things we would like to pull off, that any new directions can be forged.

For instance, there isn't a reason that an app environment couldn't be setup that routes info in a reliable way, and makes use of even more than just two compositions if it's designed to do so. There can be a myriad of qtz based compositions involved in the makeup of an app, and it's clear that it's an awesome route.

I really enjoy using qtz's as shell controllers for media, and to trigger fx sequences. It's gotten to be a bit of a passion, and I'm really all about this idea, and the idea of being able to design a qtz GUI while having it "talk" to a main viewer in an easy and straightforward way, as well as be able to create an app and load all the plugins involved in it's environment is something I feel really strongly about. I think that having multiple qtz based windows, and then traditional IB style control would be the best of both worlds.

My attitude is that being informed is just a good thing, and I would like to give a head's up to anyone who is endeavoring to do this of stuff to watch out for.

Doing image feedback loops seems to be less frocked with potential for disaster, especially when render in images are involved in certain scenarios, but it is pretty easy to make a memory leak with Core Image in even one composition.

QC can do a ton of the stuff you do in real movie special FX (save for skeletal animation and stuff like that right now), it's just that the typical working methodologies are way different. IMO, the big difference is in working frame by frame, vs. the realtime stuff that QC lends itself to.

Using QC as a tool to do some manipulation of still frames and render to movie can yield insanely amazing results if the art that's put into it is good. I really think that's going to be one of the big future uses of QC.

I think that a really inspirational way of working, for me at least, is to look at the earlier Industrial Light and Magic stuff, and do setups to replicate what they did with earlier technology. It's a great problem solving exercise, and you realize that we actually have a tool way better than what they had for many great looking effects, it's just that we don't work it as hard, or have a big staff simultaneously working on our personal qtz's :)

Can you imagine what the Disney crew of the 50's and 60's would have done with QC? I would love to see a team with that kind of work ethic and organization endeavor to use QC in a production film based production scenario (not to take away anything from the present day crew).

Though I must admit, with special FX, I'm actually really fond of the era right before CGI stuff got really big, when they actually had to blow up cars, or make wax mannequins and do stop frame recording when they wanted someone's head to melt or whatever :)

cybero's picture
Re: Network transmition

gtoledo3 wrote:
Can you imagine what the Disney crew of the 50's and 60's would have done with QC? I would love to see a team with that kind of work ethic and organization endeavor to use QC in a production film based production scenario (not to take away anything from the present day crew).

Though I must admit, with special FX, I'm actually really fond of the era right before CGI stuff got really big, when they actually had to blow up cars, or make wax mannequins and do stop frame recording when they wanted someone's head to melt or whatever :)

Also consider some of the earlier Sound to Light conversions, such as BBC TV's Old Grey Whistle Test and the movie Rainbow Bridge [Jimi Hendrix].

I also remember that the earlier late 20th century physical FX often had some really shaky sets and inappropriately modeled physical results - flashes and bangs too big or too small, for instance :-)

leegrosbauer's picture
Re: Network transmition

I can't disagree with any of your observations, George. They seem well considered and they are certainly well presented. I'll agree with you. I'll agree with all of it.

I just don't quite get why it is that we unswervingly purpose our efforts and discussions almost exclusively on only outputting for a few unique usage scenarios, frequently in which nobody actually uses the live compositions very much at all. I mean, the big deal with the visualists seems to be live, live, live and lets keep it that way too. Yeah, except for our compositions. I've seen your concert photos, George. Anybody running live quartz comps at those events? It's all clips, is it not?

My contention is that there are a lot more additional usage opportunities that we could attempt to purpose our efforts and discussions towards and although some of them may be plebian in appearance, I nonetheless do believe that there is just as much if not more potential for popularizing quartz composition usage in some of these other areas. But we just don't seem to be interested. That general absence of interest and curiosity in fully exploring our opportunities to popularize our medium baffles me.

mattgolsen's picture
Re: Network transmition

You bring up some very good points, when I do research on QC related work, the majority of what I find is all geared towards live work.

I use QC in a much different manner, most for a digital signage display that hooks into several data sources like SharePoint, and eventually SQL servers.

gtoledo3's picture
Re: Network transmition

Definitely live generative control of qtz's and not clips, or live control of qtz filters on vid, or the generative, or mixing both, etc., etc...

I would be really curious to see more forays into gaming and animation in particular. I think those are some other practical usage scenarios.

gtoledo3's picture
Re: Network transmition

I'm curious by what you and Lee mean by live. Webcam and digital signage are live, since they happen in realtime, right?

leegrosbauer's picture
Re: Network transmition

How could we participate in that QC usage and interest area with you, Matt? Any leads?

leegrosbauer's picture
Re: Network transmition

Yes

leegrosbauer's picture
Re: Network transmition

gtoledo3 wrote:
Definitely live generative control of qtz's and not clips, or live control of qtz filters on vid, or the generative, or mixing both, etc., etc...
Ok. In that case I stand corrected. I nonetheless remain skeptical about an overwhelming prevalence of that technique, but I'll defer to your knowledge on the matter.

gtoledo3's picture
Re: Network transmition

I don't really know what people do or don't do, except what I gather from reading on the Developer list, looking here, and looking at new software releases. I also like to check out a few magazines on interactive art and tech.

I wonder what the most common mainstream use of Quartz Composer tech is? I tend to think it's in Apple's own apps, but I don't know if that counts. I do like that they eat their own dog food... it's really tasty, that's for sure :) Photobooth, and various core image based freeware editors have to be where many people that don't have much of an idea about qtz's see the technology, even if they don't know what it is. A decent amount of desktop productivity type software uses Quartz Composer as well. Then, there is always "screen saver" land and audio visualizer-ville.

What I think is so impressive about your approach is that you are using the web as a backend! I mean... when you take two steps back and consider that here you are generating live visuals on the fly that you can manipulate in all kind of ways, and send them anywhere in the world in real time with minimal latency, it's almost unreal. We have come quite a far way since dial up!

I really like the idea of QC pieces as almost moving paintings in some cases, but that is probably the most rare-ified standard to meet (and one that you tend to go for and achieve, in my eyes). I think it would be a blast to see a gallery that was a bunch of QC art on amazing video screens, updated by artists around the world on a regular basis.

I would bet that some of the coolest uses for QC probably haven't even been thought of by anyone yet! At some point, handheld portables are going to have enough juice to run things like QC, and we'll see it, or something like it, on little handhelds. That will be a real jaw dropper when that day comes... to have come from rotary phone to having a phone+animation factory+web browser+pseudo telepathy synth (or text/IM as people call it)+ who knows what else, all in a handheld. Heck, having a "notebook" computer that I can take around and do all with this actually makes me take pause every so often.

I love that QC's such a great abstraction for handling a great amount of the power of OS X. It seems almost infinite in ability in that regard.

leegrosbauer's picture
Re: Network transmition

I too wonder what the most common mainstream Quartz Composer usage is. I don't know the answer. Wouldn't it be handy to have a simple listing of applications and user count for each of them. ah, well ...

As for your reference to my own interest areas: It's clear that you fully understand my preferences and intent. Thanks for that. I myself feel that my desire for increased QC related communication and presentation usage is merely a wish to act upon the promises which are inherent in iChat but which are seemingly unfulfilled due to cross platform issues and various operating system loyalties amongst the general public. There isn't much that I advocate for that can't also be found in some variation or another right there on Apple's own iChat promotional pages. What I have come to suspect is that, in the bigger context amongst the general populace, very few people actually care much about iChat and it's promises. And I also suspect that the probable reason for this is hinted at in your closing comments regarding handhelds. That's probably where everybody else wants it to happen too.

Well, I'll just keep plugging along and trying to get folks interacting directly, live and in realtime, as best as I can and without driving everybody crazy in the process. Sorry if I get discouraged about it once in a while. I'm too old to await the arrival of sufficient power on handhelds. For me, it's now or nothing. heh. I'll try to keep it tasteful and subdued. Thanks for your attention, George. Sincerely appreciated.

dust's picture
Re: Network transmition

i think the most common QC use would be motion graphics cause that is what isit does but it seems honestly seeing that apple uses it alot it would be used for system development. i bet there are more artists out there using it than there are developers at apple using it to make system stuff ?

cybero's picture
Re: Network transmition

I finally got around to setting up a Skype session, am awaiting to see if the VNC screen sharing approach is actually more efficient over a standard connection between clients of homogenous or heterogeneous networking type.

Will post back my results, but am pleased to report that a continuous line of chat and screen sharing , in miniature mode, was easily achieved within Skype.

leegrosbauer's picture
Re: Network transmition

Excellent, gentlemen!

I can personally attest to the efficacy of Dust's composition broadcasting efforts, documented in another thread. Please note his assertions that cross platform viewership, at good resolutions, of 400 individuals or more is easily achievable by merely using a laptop. If fully accurate, this is a very significant circumstance, imho. For comparison, it's my impression that many commonplace presentation venues would be pleased enough to realize an audience of that size on a regular basis.