Gigantiq - a tale of desmeasured greed.

[DaBotz]

Thanks, Aerendraca.

It is true. My little "UBiQ" works well.
 
I started populating the keyboard with my short-cuts labels.

I also realized that imwheel - the utility I use to "hook" the wheels to GIMP functions - while it is much more limited than Windows' HidMacros on the inputs "it sees" (but, in GIMP shortcus are all fully programmable, so HidMacros would not be really needed even if there was a Linux version of it) , on the other side it not only allows to program the wheels output depending on the active window name but, also, on which modifier is pressed.

So, right now, I have set:

Left Wheel:
  No modifiers: Zoom
  Shift: Select next/previous layer   
  Control: Layer Opacity
  Shift+Control: Move Layer Up/Down the layers pile

Right Wheel:
  No modifers: Brush Size
  Shift: Brush Angle (useful for some brushes like, for example, "grass")  
  On Ctrl: Brush Opacity
  Shift+Control: Brush Hardness

I realize now that it would have been better to "disable" the "Fn" button, when I opened the keyboard - it would have been enough just to slip a bit of duct tape between the membranes, to achieve it.

Had I did it, now it would be easy to "fuse" that key with Control, to have a bigger (easier to push) Ctrl button ("Fn" keys are confusing enough with a straight keyboard; with it stacked vertically they have almost no meaning).

Alas, I didn't.
 
Also, I think that with a little effort I can get the wheels to "Switch mode" in the same way of the touch ring in the Intous4, though I think I would use the two unused mouse buttons at the bottom of the dashboard, and not the buttons below the wheels to control things...

[DaBotz]

Horrible Update

The romance between UBiQ and Ubuntu is no more!!!!

Apparently, there is an update (in the linuxwacom driver, or somewhere else) that "breaks" the driver stack for Intuos and Intuos2.

Damn... I am back to use Windows7, Photoshop Elements, LazyNezumi and Hidmacros.

Grrrn.

While I was checking that it was not an hardware problem, I opened up

UBiQ, and took some shots of the interior.

Here the photos of ubiq:


     


And of the control board:

       


I must say, disappointed as I am with the  damned update, it's probably for the better.

I couldn't really use GIMP's smudge tool, and Photoshop does not see the pressure input when installed in Ubuntu.

Only, Windows is so cranky...

[DaBotz]

Added some more common mode chokes, and moced away one of the already present. This last action made a lot of difference... oddly enough, I moved it nearer the video board, but redusced problems. Why ? No idea.

17 seconds of jitter from really near the pen.

https://www.youtube.com/watch?v=Ujcv_jGPawc

If only I could get rid of what's left of it.

[Aerendraca]

Is that the worst of the jitter or are there places on the screen which are worse?

When you say you moved one of the chokes nearer the video board, do you mean the graphics card or the lvds controller?

[DaBotz]

I moved the second big filter between the the tcon board and the lvds controller, but I also rotated it 90º from the previous position, which may have broken whatever magnetic entanglement was going on in the original  position.

The screen has CCFL lights, and - as could be expected for interfering screen - jitter is worse near them, becoming quickly unusable in the last 10 mm nearing the edge.

Oddly enough, it is not as bad near the lower lamp as it is near the upper lamp, where I suppose the tcon board is not fully shielded.
 
The main effect seems to be a "distortion" on the y axis reading of the position of the pen (where the general Jitter is, instead, mainly an x axis issue: looking at the driver test page, aside the worrying tool serial number 0x00000001, both x axis tilt and position jitter is more than twice that on the y axis).

The pen appears to "leave" the cursor behind, but I am not able to tell whether it is the lamp, or the metallic case still present distorting the electromagnetic field in that zone, the source of the issue.

Combined with the tablet not reaching the left and right borders, I'd say that it is better to keep the drawing area inside of 2 cm from each border, which suits me well.

As a long time paper dog, the border area is sacred for me (it's used to hold the paper on watercolours, or editorial annotations on comics...) and I never go there on paper, even when drawing sketches.

Also, the unusable space is mainly occupied by the Windows status bar (on the right), the Photoshop status bar (bottom), the Photoshop toolbox (on the left - I don't really need to reach it, as I use hotkeys for tool selection, but it is a bit difficult to get what is your current tool without it) and other seldom used PS options (top).

________________________________________________________________________________________________


On a side note, I moved the UBiQ where I used to keep the CabinetiQ (Simply, I can't concentrate much on a sofá).

So, I finally found why C..Q was so randomly, with his jitter.

The earth dispersal is less than ideal, and noise just goes around from one appliance to the other (no idea how much would cost fix it... more than change the screen to a less jittery one, for sure).

In the new place, some random clicks are back and jitter is a bit worse, and gets a lot worse when the other computers - and monitors - in the room are active. Or if the hard drives work hard.

Also, there is some more jitter near the vertical edges, than what was there in my flat. I suppose it is a matter of the ground not dispersing the noise generated by the ccfl in the metal casing.

Finally, I'd say that the main problem is still not what I call "random" jitter (which could be mitigated a bit more, maybe) , but rather what I call "geographical" jitter.

This is shot of a line made with a ruler, going back and forth five times.



The random jitter is the reason why the line is not just 3 pixels wide, but the overall wavy shape is a proof of the presence of a "fixed" decorrelation between the movement on x and y axis, that depends on the position/movement of the pen (by the way, also my beloved Huion H610 has the same issue, and that without placing a screen over it).   


_________________________________________________________________


On a side note, I have an half Idea of building a couple of capacitive "wheels" and some touch buttons, to place under the glass.

I bought an Arduino clone that should arrive next week, and it seems simple enough. Maybe.   

I've seen a library that would do the trick, using one digital out as " source" and measuring the time that the various pins need to react, and I think two wheels would "eat" up 7 digitals I.O. , leaving 7 inputs for buttons.

Not so easy... the tricky part is designing the wheel plates, taking into account that the glass is 3mm thick, and then the software so that it ignore false touches.

On the other hand, the rotary encoders in my current, repurposed mouse wheels have a 15º step (24 positions in a complete turn), and I am not sure that I can manage to be able to do the same (the issue, mainly, being the glass thickness getting in the way of the single sensor spatial sensibility... the examples I have seen around, of pcb with drawn wheels, have something like 5 sectors).   

[DaBotz]

I started looking into the capacitive commands idea...

It looks like a lot more experimental than the rest of the stuff.

I hooked up the Arduino clone to a breadboard, with one 5M resistor, and a whole a4 sheet of aluminum foil as sensor, below a 3mm thick glass. It saw my hand from around 10 cm above the glass.

So, I cut out "the excess" of foil, and left a "sensor" of, more or less, the probable size of a finished button.
; the end result is something like this:



I based the trick on a library that can be found at http://playground.arduino.cc/Main/CapacitiveSensor

I tried various values for the resistor, but for the moment I do not know what to make of the first results.

The whole gig seems to be a lot more "temperamental" than I'd really like it to be.

I hope I will be able to tell more, soon.



 

[Aerendraca]

I think the reason its temperamental is because you don't have a ground plane for the switch. I think its the case that whilst you can get a capacitive button to work while it's 'floating', it becomes alot more stable when you have another piece of foil that is connected to ground and placed underneath separated with some tape. The point of this is to pull the capacitive button towards ground making it less floaty. This is typically how capacitive buttons are made up on PCBs.

[DaBotz]

Thanks, I forgot that detail.

As ground, should I use the GND pin of the Arduino (which, I suppose, is the GND of the USB, and, through this, is grounded to the PC and the general ground dispersal), or would it be better to connect directly to grid's ground?

Oh, well' I'll see, next time I try.

For now, the oddest thing was that when I touched the glass, the capacity went DOWN, when she's supposed to rise. That was really baffling...

Thanks again, aerendraca.

[Aerendraca]

Yes, I think it should be the ground of the arduino. Not sure about the capacitance going down, probably just an anomaly related to the absence of a ground.

[DaBotz]

I still can't figure head or tail, of the capacitive side of things.

To restore my self-esteem, I tacled one of the issues of my set-up.

Namely that hidmacros, handy as it may be, does not switch configuration on a window name base, like the intuos driver can.


I wrote a small java program that kills HM, changes the hidmacros.xml file, and then restarts HM, when the foreground window change and it happens that the new window has associated a set of macros.

You can find it here: 

https://www.dropbox.com/sh/ul13bv7xy86pxkg/AACuTFcLK-JcTZDFOFC86CVMa?dl=0

it must be placed in the same directory as HIDMacros .exe.

When launched, he launches HIDMacros and then creates a directory called repository (or something, I may change it).

This will contain a "lock" file (to avoid launching more than one instance of the daemon), a list of ignored applications (explore.exe and others) which will be considered non existing, an xml file containing the skeleton of the macro it uses to "mark" each file, and a directory called "macros" containing a copy of the current hidmacros.xml configuration file (called, instead, generic_application.stored.xml).

Here, more copies will be added.

All the saved files are simply text, so you can change them as you better saw fit (as long as you do not "break" them... aside from the xml, the others are just columns of application's names, with no trailing spaces).

When hidmacros saves his config file, the daemon saves a copy of it in the repository, marking it with a "bogus" macro (actually, it's a"loopback" macro, that tells the daemon to show a credit message) and procedes, from then on, to replace the hidmacros file when you work with that window.

Said copy will be associated to the last "acceptable" window to have been in foreground (when you save using save configuration... Note: if the daemon needs to mark the macros set, it will kill and relaunch hidmacros so that the added/modified mark macro is visible).

It attaches an icon in the tray, through which he can be controlled.

On a double clicks, it shows the macro sets presently defined.

Right click, it shows a menu with stop, enable-desable-delete macros sets, enable/disable expansion mode options.

With the expansion mode disabled, "unknown" application are treated as instances of a "generic application", and thus a macro set named "generic application" is used.
As I said, it is just a copy of the hidmacros.xml file that was there when the daemon was first launched, but it can be modified as every other app.

When "expansion" is enabled, unknown applications are ignored till HIDmacros does not save his macros. Then, the recently saved set of macros is "hijacked" and used as that application, specific, set.

So, let's say I need to "port" the macros form photoshop to Manga studio.

All I have to do is open Photoshop, wait for the daemon to popping me that the switch of HM config has been done (unless the current is a file marked to be used with Photosop, however it takes an half second... I trimmed its timing more for less resource consumption than for user-friendliness), then alt-tab to manga studio and then, tab to hidmacros and re-save the configuration.

The daemon will see to it that that config will be saved as the one for Manga studio.

It is pretty crude, and probably can and should be tweaked-developed a lot (for example, could be added a "sudden-death, restart after a couple of minutes" feature, so that when you touch a dead accent key in your "main" keyboard, hidmacros is killed for a while, or a way to add some arbitrary modifier key) but, for the time being, this is as far as I can go with it.

If someone is proficient with java and wants to pick it up, the jar also contains the source code and the project files from Eclipse.

I know, it's an unholy mess... it is a couple of years that I do not program, so all the good habits were lost.

[Aerendraca]

Excellent work DaBotz! I'll have to give this a go as it could be super useful in the future when i try to implement a leap motion controller to my build.

I think a whole bunch of bongofishes will find this tool useful.

[DaBotz]

I hope it wil be appreciated.

Right now, my PC still runs on XP (HM relies on directInput, so it has some issues with mouses in Windows 7, for example), so it is tested only for that -
I hope it still works on other Windows(es).

However, the source code is inside the jar (alas, compiled and sources are "meshed", there is no separate "src folder"), so it should be simple to fix the errors that would arise on newer OS.
Maybe.

[DaBotz]

I placed a revision of the "daemon" in the folder.

It no longer shuts down automatically when Hidmacros stops, rather I reversed the relationship... always
checking for HM was rather a resource hog, and sometimes misfired too. 

This version also allows to define "modifiers", i.e. a way to have more than one hot-keys layout for each application.


They are not so fast in response (something like a couple of seconds),  so they are not exactly the same as actual keyboard
modifier keys (Alt, Shift, Ctrl etc. ).

Also, they can't be combined... but, on the other hand, they are absolutely arbitrary, both in name, keys they are
latched onto, and duration .


Unfortunately, they are not that easy to set up.

More or less, you set the daemon in "Expanding mode", you define a macro with the modifier "call" in the base version
 of the macros you use with an application (if no "modifier" macros are present, the last version adds four sample calls),
save the macros to make it definitive, call the key that starts the modifier, wait till the demon says a new modifier
has been defined, and then save the macros again (possibly, after having switched back to the application you mean to
set the modifier for, just to be sure) so that it creates in the repository an aptly named
copy of HidMacros config file.

I'll have to build a wizard, one of these days.

[DaBotz]

It seemed that I had a mishap with the USB hub, so I opened the UBiQ and made a short video.

I know It's messy but, please, don't shot the pianist.

http://www.youtube.com/watch?v=1v0zFVrv5fE

Te actual mishap was this:
I disconnected the power cable to the screen, and hence the USB received some kind of spike that sent it in lock.

Once cut the juice again, and disconnected the usb cable, it all went back to normal.

I didn't expect UDB hubs to be able to require a complete reset...

[Aerendraca]

Nice video! That Gigantiq really is, well, gigantic! It's good to finally see the inside of your beast.