neilcsmith_net

Praxis LIVE is a hybrid visual IDE for creative coding, with included support for TinkerForge. I've just posted a major update to the documentation covering the coding of custom components (and forking of existing ones). There's also a dedicated page covering the Praxis LIVE specific extensions to the standard TinkerForge Java API. http://praxis-live.readthedocs.org/en/latest/ http://praxis-live.readthedocs.org/en/latest/coding/ http://praxis-live.readthedocs.org/en/latest/coding-tinkerforge/ Hope that's of interest to a few people on here. Happy tinkering!

Praxis LIVE is a hybrid visual IDE for working with video, audio, MIDI, OSC ... and, of course, TinkerForge! Version 2 features two major changes, both of which impact on TinkerForge usage. New Code API - version 2 massively extends live-code support, providing the ability to define and re-define built-in and custom components at runtime. Distributed Hubs - projects can now be run across multiple computers. All of the TinkerForge code in Praxis LIVE has been rewritten to use the new code API. So, while there aren't (yet) additional bindings, because I'm reluctant to release code I can't test, it is possible to create a custom TinkerForge binding, or fork an existing one, to interface with any brick(let). And you can do this while your project is running. Have a look at the code for the built-in Distance IR bricklet binding. Note the use of annotations - the Praxis LIVE environment handles all device discovery and threading automatically. Of course, if you're not happy coding, the new code API also makes it easier to share custom components - I'm happy to write if you're happy to test! The distributed hub support is interesting because it allows for TinkerForge components to be connected to a different (or many different!) computers from the one you're controlling your project from. It should be possible to run the command-line slave on a Pi or RED brick, too, though I haven't yet tested. I can also create a lightweight build without audio/video modules if there's a desire for that. Thanks for your interest, Neil

OK, getting there! So, the initial switch to working with this seems to be working fine - no issues so far. I'm now working on integrating the live code support (as per my first post), which will really test this. Two related (on my end) things - * As the live code works by creating a delegate on each compile, the Device is injected as a field. To counter the possibility of hanging listeners causing the old delegate not to be GC'd, I'm thinking of creating a new Device each time to inject. Is creating a new Device the only way to disconnect a Device from IPConnection, and more importantly force its listeners to be disconnected? This could potentially be creating 10's or 100's of devices bound to the same UID as the user iterates code. Any issues with doing this? * Is there a map of device identifier to Java class anywhere? Slightly hoping not as I wrote one yesterday and it was tedious! It could be a good addition to the bindings? (I'm creating the Device subclasses using reflection) Thanks for all your help and support, Neil

Not enough! Sorry, the last few weeks have been hectic (I also work on Drupal websites, and you might have seen the rather major security flaw that hit last month!). So, now alpha 3 of Praxis LIVE v2 is out, I'll be working over the next few weeks on things that will properly test this - enabling live coding of TinkerForge bindings is scheduled for alpha 4. Incidentally, alpha 3 finally made distributed hubs a reality - I'm hoping this will (amongst other things) be good for working with the RED bricks.

Fantastic! Just what's required. I'll do some testing over the next week or so, and hopefully not uncover any issues. Thanks, Neil

Great! Thanks for this. If you mean your previous prototype, I thought that was the point of the Semaphore and while loop? I can understand the problem with trying to execute the dispatchMeta reconnection stuff asynchronously. Why is this required though? Surely this is just a notification that a disconnect has happened. I guess it may limit some things you can do in the listener. I was hoping to get away from synchronous dispatch if possible, though can handle that if it's the only way. I had looked a bit at this approach before my first message, and couldn't see any obvious issues with asynchronous dispatch - the data passed into the call.. methods doesn't seem to be reused anywhere (eg. the data array is created each time as far as I can tell). And me! This should save me the hard work of trying to keep a fork of the bindings up-to-date anyway. Thanks again, Neil

I was aware of that - I said "possibly". Looks interesting. Haven't tried yet (will test), but initial question would be - doing it this way does the CallbackThread have to wait on the callback dispatch - presume this may be to do with the dispatchMeta() reconnection management? In fact, having the reconnection code running on an event thread might be a bad idea. I wonder if this may be too complicated and invasive an approach? What about the listeners themselves? Can you foresee an issue with them being called asynchronously? The other option (as per my initial post) that would work for me would be to be able to override callDeviceListener(..) Could all the abstract call.. methods in IPConnectionBase be made protected so that we can override them? Can you envisage any issue with doing this? eg. protected void callDeviceListener(final Device device, final byte functionID, final byte[] data) { EventQueue.invokeLater(new Runnable() { IPConnection.super.callDeviceListener(device, functionID, data); } } JFTR, I'm not looking specifically to invoke them on the Swing thread - each Praxis root has its own event thread and similar invokeLater(..) method.

Thanks for the responses. That would possibly meet my needs, though I was really looking to do this without the external thread needing to poll. Rather than setAutomaticCallbackDispatch(false), what about a setCallbackDispatcher(CallbackDispatcher ..) method that can be set on IPConnection, with an interface called every time a callback is added to the queue? interface CallbackDispatcher { public void callbackReceived(); } Then you could do things like SwingCallbackDispatcher implements CallbackDispatcher { public void callbackReceived() { EventQueue.invokeLater(new Runnable() { dispatchCallbacks(); } } } And get all callbacks on the Swing event queue? Likewise for JavaFX. It could simplify having to duplicate this in the body of every callback if you need to update a UI. You could possibly even simplify the current CallbackThread code by replacing with a default CallbackDispatcher that has a single threaded executor - should handle Exceptions by itself? Just a thought .. Thanks, Neil

Hi, In short - would it be possible in future to extend the (Java) IPConnection API to allow a different external thread to call in and drain the callback queue? In full - I'm currently working hard on v2 of Praxis LIVE. One major feature coming is that (almost) all components will be defined and compiled at runtime using a new custom code API - a big step towards my original vision of a visual patcher environment where you can fork and alter / extend any component as a patch runs. It should also make it easier for anyone to provide bindings for additional TinkerForge components that I don't have access to test. Now, the problem is that each patch root in Praxis LIVE is single threaded, and currently the TinkerForge bindings have to handle callbacks by re-queueing and invoking code on the right thread. Opening this up as-is feels far too complex and error prone. For now, I may try hacking an in-package extension of IPConnection that overrides callDeviceListener(), but it would be nice to have a proper and more efficient API to handle this sort of use case. Incidentally, another major feature in v2 will be distributed hubs, allowing patches to run across multiple machines - I'm hoping the RED brick might be capable of running a Praxis slave! Best wishes, Neil

All new website at www,praxislive.org and a new release brings bindings for IO16, Joystick and Linear Poti bricklets; and the Servo brick. I've also improved various things about the existing component bindings, and added the ability to use an <auto> UID so it's easier to get started. If anyone's got any thoughts or feedback on this it'd be welcomed. I'm looking to make Praxis LIVE usable as a comprehensive visual RAD for TinkerForge before the end of the year, and hopefully in the next couple of months. Will do a blog post and more documentation on the usage of this ASAP.

This took a backseat for a while due to other commitments, but finally got around to updating the Praxis LIVE TinkerForge bindings to v2. This still only covers the starter kit components, but will be looking to improve this situation ASAP. A couple of questions - I'm planning to purchase further components soon, but probably only those that I am likely to make use of. I'd like to make the Praxis LIVE bindings comprehensive but can't justify (or afford! ) everything. Is there any way to get access to other components for purposes of coding / testing the bindings? Or someone willing to test? Are there any plans at the moment for a visual RAD environment for TinkerForge? If not, is that something you'd be interested in? A role Praxis LIVE could play? @borg - a belated thank you for the short but sweet feedback!

Hi All and Happy New Year! A couple of months back I added some basic TinkerForge support into Praxis LIVE, an open-source visual development environment for working with audio, video and other media. This is included in the recent (121231) release, though somewhat hidden away at the moment - I put development of this on hold pending the v2.0 protocol. Thought some of you might be interested in having a look or seeing a . There's only currently bindings for the starter kit components - the intention is to add the rest once the new protocol is release, and I can either afford more components or find willing testers. Feedback on what's there so far would be great. Thanks and best wishes, Neil

Oops! Misread the size and how quickly that wraps. That wasn't my intended meaning of "fail fast"! How about a hash of UID, function ID and (if needed) sequence ID? The idea being that this is all managed in IP connection. You could theoretically put the existing API on top of the Future one - creating methods that block and timeout on the Future.get(). I realise the need to keep this simple for someone just starting to learn programming - at the same time, that timeout could be a big gotcha for the beginner too!

Good to know, and shouldn't make updating too hard. I guess there's no easy way of making the bindings work with either protocol is there? Yes, I came close to forking the current bindings to do that, but have ended up going with an approach that I don't have to (essentially an intermediary proxy that is updated by callbacks). However, I still believe that Futures or something similar would be useful in the bindings; or, at least given the new protocol's intention to handle parts of the system being unavailable, a way of making things fail fast. Maybe I'm wrong, but in the current bindings doesn't any message that is not replied to cause the call to timeout - essentially bringing everything juddering to a halt for 2.5 seconds? Yes, though my thought was more along the lines of a single map of sequence number to Future held in the IP connection. The new spec does talk about you not guaranteeing correct sequence order in future!

Well, I thought I'd make the first English response - have tried to follow some of the discussion in the German forum with Chrome's auto-translate. Not very easy! The new protocol seems a good step, though hopefully updating software to work with them won't be too difficult. Having last week written the bulk of the infrastructure for binding with Praxis, I particularly like the planned improvements to enumeration. One thing I find somewhat frustrating is the current blocking / timeout mechanism for some methods (particularly as Praxis is designed around a non-blocking architecture so I have to work around it!). Given the desire to make things work more robustly in case of failure, and with the addition of the sequence number to the protocol, might it be possible to rethink the bindings to return Futures rather than actual values? I'm working with Java where this would be fairly easy to implement using a map of ID to Future. I'm not sure how easy it would be across all the languages you're supporting though. Best wishes, Neil