Forum Replies Created
-
Posts
-
Works for me but as you’ve given us almost no details it’s hard to know where to begin:
Which Resolume product?
Which AirBeam product(s) and device(s)?This is almost certainly happening in whatever application you’re sending from – perhaps because some apps have different settings for Syphon output than regular output – what is it?
The list of available servers is liable to change fairly often, so providing a way to know if it has changed seems a useful thing. The most obvious scenario is when a user launches their Processing sketch and then launches a server app afterwards – you’ll have a new server appear a few seconds/mouse-clicks after launch.
Internally, SyphonServerDirectory passively requests servers announce themselves when it loads and maintains a list locally which is returned by the servers method. As in the rest of the framework, not blocking is a feature, to avoid hung applications hanging other apps.
Unless Processing provides a way to deliver notifications and users are accustomed to using that, having a ServerListHasChanged() (or similar) method paired with a non-blocking ServerList() method is the simplest arrangement I can think of.
I don’t expect being able to list servers to be a much-used feature for Processing – most people will be happy to hard-code a particular server by name, or any available server if you permit that as per my comment on the serverName/appName issue on google code.
Forgive slow responses – currently working on a show.
Thanks for your recent activities on this – really good to see Processing support become solid.
Assuming polling is what people are used to in Processing:
I’d rather avoid the sleep. How about registering for SyphonServerDirectory’s notifications, and have a ServerListHasChanged() method? Users can poll that and it will return true if you’ve received a notification since they last queried it or called listServers. At that point they can call listServers().
If sleep happens on the main thread, it may block the discovery process too. Just as an experiment try doing it on a key press or somesuch, and see if you get any valid servers.
Ah I get to type at you in two channels now 😉
Are you doing this as soon as Syphon is loaded? It takes a moment for server discovery to happen. Otherwise the code looks good.
The anti-aliasing is happening at the drawing stage in the client apps – normally it’s desirable to draw upscaled content with anti-aliasing.
For presentation on a > 10×10 display, I would do the resizing yourself prior to sending it to Syphon so you can control the process. For what it’s worth, you could try filing a feature request for MadMapper to be able to skip anti-aliasing.
If you’re presenting it on a 10×10 device, make sure your output resolution in MadMapper is set to 10×10.
For recording, if you record at > 10×10 then it is likely to be anti-aliased during recording. If you record at 10×10 then you should get a faithful copy of the original – but of course if you play it back above its original resolution then the player is likely to anti-alias it for display.
I don’t have Processing on the machine I’m typing on right now, but looking at the source it looks like it actually matches the name of the app, and not the server – so try “Max”.
That’s a bit goofy of the Processing implementation. I’ve opened an issue to remind us it should work the same as the other implementations – it will get fixed someday…
What audio device are you recording from? Could you post a screenshot of your Preferences window in Syphon Recorder?
If you could post a screenshot of the setup that wasn’t working, it would help us fix it – selecting no audio should work. Cheers.
First off, recent versions of VDMX have a Movie Recorder plugin which will record inside VDMX, saving the need for the Syphon stage. Performance is good.
If you’d still like to use Syphon Recorder for whatever reason and it’s not working for you, please post a photo of the Preferences window inside Syphon Recorder showing the settings you are attempting to use.
Can you provide minimal materials to reproduce this? e-mail contact@v002.info if that’s easier. Cheers
This shouldn’t happen.
It would be good to reduce this to a simple case – if you run Simple Server and Simple Client ( http://syphon-implementations.googlecode.com/files/Syphon%20Demo%20Apps%20Public%20Beta%202.dmg ), do you see the glitches?
Ah – does anything get logged to the console (Applications > Utilities > Console) when you start a recording with the the Audio 8 DJ?
I’ll have a look – but it seems it might be difficult to diagnose without access to the device. You might want to use Soundflower in the interim.
Sorry yea, I was wrong – stop doesn’t release the handler.
What I do in such cases is create a container object which has everything the handler needs to function which the handler and the client can both retain without causing a retain loop.
Circumventing the retain rather misses the point – you don’t want your object being released while the block is still executing.
As a note, once you call -stop on the client, the handler is released (and with it, anything it retained).
Not sure if beta 3 is supported – our last Processing release was for beta 2.
Either way, do you have a Syphon server named “woot”? If not, that’s why…
This has nothing to do with Syphon.
