Are no artists from traditional media using Processing? (Re: lack of stylus libraries)

joeproc

Codeanticode's Tablet library looks pretty dead now (which looks like it's due to Jpen, a dependancy, dying). This has been the case for some time now and nothing has taken its place. And nothing really competed it with it when it existed.

Am I wrong in thinking, with the prevalence of Wacom tablets still in use by professional artists, that this may be an indication of waning interest in Processing from this side of the industry? For all of its intentions to combine programmability and art, it's frustrating that one of the more creative and widely used inputs (a stylus) has little interest in terms of libraries. Or is there any alternatives I'm missing?

If you look at my comment history you'll see that this topic is all I've been interested in. The ability to create a library is beyond my skill level but I thought a replacement for Tablet would have occurred by now, given the industry and interests the software is aimed at.

jeremydouglass

Not sure -- last commits to it were from @codeanticode earlier this year? Looks like they are more recent than the last release, if that matters....

• https://github.com/codeanticode/tablet
• https://github.com/codeanticode/tablet/releases
• https://github.com/codeanticode/tablet/commits/master

jeremydouglass

I'm curious --

1. are you specifically referring to Wacom pressure tablets or screen tablets?
2. you mentioned JPen dying. are there other sets of drivers and other Java libraries, other than JPen, that you are specifically aware of?

joeproc

The latest commits to Tablet were at a time when I was discussing it with @codeanticode. The guy seems up to his neck, I'm not surprised he can't do more. I was just surprised that - without his work - nobody else was interested in getting a working library going, which I took as an indication of interest in this area.

The issue is primarily that Processing will not register tablet pressure from the P2D/P3D/OPENGL renderers through the Tablet library a majority of the time it's run. I say majority as it haphazardly works every few restarts. The JAVA2D renderer works but its crude rendering makes it semi-redundant for most needs of using a pressure-senstive stylus.

In answer to your questions:

1. Both. I believe the issue is across Wacom's Intuos, Cintiq and Bamboo devices. I can't test but the issue may be beyond Wacom branded stylus. Apart from Apple's iPencil, few professionals are using anything outside of the Wacom brand. It has the monopoly in the area.

2. I may have seen some blips of java pen libraries that were unfinished or outdated with little uptake during my research. Beyond that, I was only aware of JWINPointer and Wacom's own SDK availability. There's mention of using a TUIO solution such as SMT. I haven't look deeply into it as my reading suggested there was difficulty in getting it to work with pen stylus and - looking at its documentation - it focuses on other input devices, barely mentioning TUIO and with no specifics towards pen stylus. I was hesitant to go down the hole with seemingly no reward at the end.

It's my understanding that, prior to Tablet existing, people were focusing on using JPen with Processing. I've seen little discussion of JWINPointer, which doesn't mean it hasn't merit in the area but I'm unable to check it out as I'm on a mac. I haven't seen anyone mention integrating Wacom's own SDK with Processing. I'm not even sure if the Java SDK is intended for something like this.

codeanticode

@joeproc thanks for bringing this topic up. It is a shame to lose stylus support in Processing, but I don't know what a good solution could be. I'm curious about Wacom's Java SDK, but seems that one has to contact them first to get access. Perhaps is worth sending them a message describing the problem and see what they say.

joeproc

I wasn't actually expecting much of an uptake on this but thought it was worth putting out there as it felt like a shame for this medium to burn out in terms of its use with Processing.

I would have thought Wacom were too large now to entertain small queries like this but there's nothing to lose in me trying. If there's any response worth sharing I'll report back.

joeproc

Update

Wacom's site had a 'Request the SDK' contact form. After a few days I got a reply that said I'd contacted customer support and they were unable to transfer my request to Development. I double checked I'd clicked the only option for 'Request the SDK', so that didn't instil much confidence of getting a dialogue from Wacom on the SDKs usage in Processing/Java.

However, it did suggest I look at the other development part of the site (the development documentation and marketing is quite fragmented) and I found that Wacom are using various acronym names to sell various implementations of their SDK for broader uses such as signature id detection, mood detection, etc. It's actually a nice idea but made it a little unclear as to what option to choose to get basic pressure and angle support in java, rather than implementing security or mood features.

Most of the SDKs are commercially licensed but the only one that I saw that wasn't, WILL SDK Community Edition was available for Windows, iOS, Android and Web for non-commercial uses. You'll need to create a free Wacom ID to access the downloads.

Being on a Mac, wanting a Java SDK, and not being too versed in this area I wasn't confident as to whether any of the options were relevant: Web gave me a javascript SDK. Android gave me a Java SDK in the form of an AAR rather than JAR (though I've been led to believe that a JAR file is easily obtainable from an AAR). I've no idea if this is straightforward to implement in any Java environment or if that's a nightmare/impossible if working outside of the Android platform.

I'll dig further into the available downloads and documentation but I thought I'd offer this progress up here incase it's informative in any way or somebody can clarify any of my confusion.

joeproc

I'm afraid I'm definitely way out of my depth here. Finding that AARs are just using zip compression, I was unable to unearth the WILL SDK jar, which was also basically a compressed collection of java code.

I was afraid that I'd strayed so far from the original AAR in terms of file hierarchy and expected files that it would be overly optimistic to expect the isolated java code of the JAR to work autonomously as a library with a little tweaking. It seems to be the case and, if not, I can't make sense of where to begin tweaking.

I'm assuming that making a working Processing library from an SDK library intended for Android devices is not a simple conversion.

jeremydouglass

If they are distributing AARs for Android, specifically, you might also look at Processing Android Mode.

It sounds like this situation goes far beyond interest on the Processing -- if I am understanding you right, the Java community at large isn't using Wacom with Java because Wacom isn't invested in supporting a (non-commercial) plain Java SDK. If that is the ongoing situation, then a heroic effort now might result in a temporary breakthrough, but may still result in chasing a moving target in the form of Wacom's evolving API.