Our great sponsors
-
Brain
Arduino library for reading Neurosky EEG brainwave data. (Tested with the MindFlex and Force Trainer toys.) (by kitschpatrol)
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
dragonfly
Speech recognition framework allowing powerful Python-based scripting and extension of Dragon NaturallySpeaking (DNS), Windows Speech Recognition (WSR), Kaldi and CMU Pocket Sphinx (by dictation-toolbox)
-
PrecisionGazeMouse
Precisely move your mouse by gazing at a point on the screen or by moving your head
-
BlinkPoseAndSwipeiOSMLKit
A Tinder Swiping Card Prototype that does touch less swipe, using face gestures.
I've been working on the menuing side [1] based on crossing Fitt's Law with Huffman trees. But, don't know the constraints for ALS.
Hopefully, whomever takes this on doesn't take the standard Accessibility approach, which is adding an extra layer of complexity on an existing UI.
A good friend, Gordon Fuller, found out he was going blind. So, he co-founded one of the first VR startups in the 90's. Why? For wayfinding.
What we came up with a concept of Universal design. Start over from first principles. Seeing Gordon use an Accessible UI is painful to watch, it takes three times as many steps to navigate and confirm. So, what is the factor? 0.3 X?
Imagine if we could refactor all apps with a LLM, and then couple it with an auto compete menu. Within that menu is personal history of all your past transversals.
What would be the result? A 10X? Would my sister in a wheelchair be able to use it? Would love to find out!
[1] https://github.com/musesum/DeepMenu
Okay, so, your comment about a "Dasher + Guitar Hero music theory/improvisation practice program" just sent me down a huge rabbit hole...
Well, rabbit hole(s) plural, I guess, most not directly related. :D
Largely because I made the "mistake" of looking at your HN profile & discovering you're also in NZ & we seem to have somewhat overlapping interests (and an affinity for "bacon" in account names, apparently), so, some thoughts[0]... :)
# Topic 1: Nissan Leaf VSP hacking
After reading your recent posts (https://ianrrees.github.io//2023/07/03/vsp-hacking.html & https://ianrrees.github.io//2023/08/05/voltage-glitch-inject...) on this topic & noting your remark about wanting to try reverse engineering a firmware image, I found the following thesis PDF (via a brief google search for `"reverse engineer" "firmware" "Renesas"`):
* "AUTOMOTIVE FIRMWARE EXTRACTION AND ANALYSIS TECHNIQUES" by Jan Van den Herrewegen https://etheses.bham.ac.uk/id/eprint/11516/1/VandenHerrewege...
Not really what I was anticipating finding but seems relevant to your interests--I don't think it was already in your resource list.
While the thesis addresses the Renesas 78K0 rather than the Renesas 78K0R, from a brief look at the "Flash Protection" PDF Application Note in your resource list it seems there's a large overlap.
Perhaps most significantly the author presents "novel methods" that combine bootloader binary analysis with constraint-based power glitching in an effort to improve on the results described in "Shaping the Glitch".
While I haven't read the entire 186 pages :D they theorize that using their approach extracting 8kB firmware might only take ~10 hours.
And, most helpfully, they even published their source code under the GPL here: https://github.com/janvdherrewegen/bootl-attacks
So, an interesting adjacent read even if it turns out not to be directly applicable to your situation.
Given I have an interest in & a little experience with firmware reversing my original thought was to maybe provide some hopefully helpful references that more generically related to firmware reversing but more specific is good too, I guess. :)
In terms of reverse engineering tooling, I've used Rizin/Cutter/radare2 previously: https://rizin.re https://cutter.re
On the CAN tooling/info front, you might be interested in taking a look at my "Adequate CAN" list which I originally wrote-up for a client a couple years ago: https://gitlab.com/RancidBacon/adequate-can
Some other probably outdated reverse engineering tooling links of mine: https://web.archive.org/web/20200119074540/http://www.labrad...
In terms of how to approach RE, other than just "getting started & digging in" & learning by doing, I've sometimes found it informative to read other people's firmware reverse engineering write-ups to learn about potentially useful approaches/tools.
Anyway, hopefully some of this is helpful!
[0] I have a tendency to be a little... "verbose" and/or "thorough" (depending on one's POV :) ) so I'll probably split this over a couple of comments, in case I run out of steam while writing and for topic separation.
Okay, so, your comment about a "Dasher + Guitar Hero music theory/improvisation practice program" just sent me down a huge rabbit hole...
Well, rabbit hole(s) plural, I guess, most not directly related. :D
Largely because I made the "mistake" of looking at your HN profile & discovering you're also in NZ & we seem to have somewhat overlapping interests (and an affinity for "bacon" in account names, apparently), so, some thoughts[0]... :)
# Topic 1: Nissan Leaf VSP hacking
After reading your recent posts (https://ianrrees.github.io//2023/07/03/vsp-hacking.html & https://ianrrees.github.io//2023/08/05/voltage-glitch-inject...) on this topic & noting your remark about wanting to try reverse engineering a firmware image, I found the following thesis PDF (via a brief google search for `"reverse engineer" "firmware" "Renesas"`):
* "AUTOMOTIVE FIRMWARE EXTRACTION AND ANALYSIS TECHNIQUES" by Jan Van den Herrewegen https://etheses.bham.ac.uk/id/eprint/11516/1/VandenHerrewege...
Not really what I was anticipating finding but seems relevant to your interests--I don't think it was already in your resource list.
While the thesis addresses the Renesas 78K0 rather than the Renesas 78K0R, from a brief look at the "Flash Protection" PDF Application Note in your resource list it seems there's a large overlap.
Perhaps most significantly the author presents "novel methods" that combine bootloader binary analysis with constraint-based power glitching in an effort to improve on the results described in "Shaping the Glitch".
While I haven't read the entire 186 pages :D they theorize that using their approach extracting 8kB firmware might only take ~10 hours.
And, most helpfully, they even published their source code under the GPL here: https://github.com/janvdherrewegen/bootl-attacks
So, an interesting adjacent read even if it turns out not to be directly applicable to your situation.
Given I have an interest in & a little experience with firmware reversing my original thought was to maybe provide some hopefully helpful references that more generically related to firmware reversing but more specific is good too, I guess. :)
In terms of reverse engineering tooling, I've used Rizin/Cutter/radare2 previously: https://rizin.re https://cutter.re
On the CAN tooling/info front, you might be interested in taking a look at my "Adequate CAN" list which I originally wrote-up for a client a couple years ago: https://gitlab.com/RancidBacon/adequate-can
Some other probably outdated reverse engineering tooling links of mine: https://web.archive.org/web/20200119074540/http://www.labrad...
In terms of how to approach RE, other than just "getting started & digging in" & learning by doing, I've sometimes found it informative to read other people's firmware reverse engineering write-ups to learn about potentially useful approaches/tools.
Anyway, hopefully some of this is helpful!
[0] I have a tendency to be a little... "verbose" and/or "thorough" (depending on one's POV :) ) so I'll probably split this over a couple of comments, in case I run out of steam while writing and for topic separation.
Okay, so, your comment about a "Dasher + Guitar Hero music theory/improvisation practice program" just sent me down a huge rabbit hole...
Well, rabbit hole(s) plural, I guess, most not directly related. :D
Largely because I made the "mistake" of looking at your HN profile & discovering you're also in NZ & we seem to have somewhat overlapping interests (and an affinity for "bacon" in account names, apparently), so, some thoughts[0]... :)
# Topic 1: Nissan Leaf VSP hacking
After reading your recent posts (https://ianrrees.github.io//2023/07/03/vsp-hacking.html & https://ianrrees.github.io//2023/08/05/voltage-glitch-inject...) on this topic & noting your remark about wanting to try reverse engineering a firmware image, I found the following thesis PDF (via a brief google search for `"reverse engineer" "firmware" "Renesas"`):
* "AUTOMOTIVE FIRMWARE EXTRACTION AND ANALYSIS TECHNIQUES" by Jan Van den Herrewegen https://etheses.bham.ac.uk/id/eprint/11516/1/VandenHerrewege...
Not really what I was anticipating finding but seems relevant to your interests--I don't think it was already in your resource list.
While the thesis addresses the Renesas 78K0 rather than the Renesas 78K0R, from a brief look at the "Flash Protection" PDF Application Note in your resource list it seems there's a large overlap.
Perhaps most significantly the author presents "novel methods" that combine bootloader binary analysis with constraint-based power glitching in an effort to improve on the results described in "Shaping the Glitch".
While I haven't read the entire 186 pages :D they theorize that using their approach extracting 8kB firmware might only take ~10 hours.
And, most helpfully, they even published their source code under the GPL here: https://github.com/janvdherrewegen/bootl-attacks
So, an interesting adjacent read even if it turns out not to be directly applicable to your situation.
Given I have an interest in & a little experience with firmware reversing my original thought was to maybe provide some hopefully helpful references that more generically related to firmware reversing but more specific is good too, I guess. :)
In terms of reverse engineering tooling, I've used Rizin/Cutter/radare2 previously: https://rizin.re https://cutter.re
On the CAN tooling/info front, you might be interested in taking a look at my "Adequate CAN" list which I originally wrote-up for a client a couple years ago: https://gitlab.com/RancidBacon/adequate-can
Some other probably outdated reverse engineering tooling links of mine: https://web.archive.org/web/20200119074540/http://www.labrad...
In terms of how to approach RE, other than just "getting started & digging in" & learning by doing, I've sometimes found it informative to read other people's firmware reverse engineering write-ups to learn about potentially useful approaches/tools.
Anyway, hopefully some of this is helpful!
[0] I have a tendency to be a little... "verbose" and/or "thorough" (depending on one's POV :) ) so I'll probably split this over a couple of comments, in case I run out of steam while writing and for topic separation.
Okay, so, your comment about a "Dasher + Guitar Hero music theory/improvisation practice program" just sent me down a huge rabbit hole...
Well, rabbit hole(s) plural, I guess, most not directly related. :D
Largely because I made the "mistake" of looking at your HN profile & discovering you're also in NZ & we seem to have somewhat overlapping interests (and an affinity for "bacon" in account names, apparently), so, some thoughts[0]... :)
# Topic 1: Nissan Leaf VSP hacking
After reading your recent posts (https://ianrrees.github.io//2023/07/03/vsp-hacking.html & https://ianrrees.github.io//2023/08/05/voltage-glitch-inject...) on this topic & noting your remark about wanting to try reverse engineering a firmware image, I found the following thesis PDF (via a brief google search for `"reverse engineer" "firmware" "Renesas"`):
* "AUTOMOTIVE FIRMWARE EXTRACTION AND ANALYSIS TECHNIQUES" by Jan Van den Herrewegen https://etheses.bham.ac.uk/id/eprint/11516/1/VandenHerrewege...
Not really what I was anticipating finding but seems relevant to your interests--I don't think it was already in your resource list.
While the thesis addresses the Renesas 78K0 rather than the Renesas 78K0R, from a brief look at the "Flash Protection" PDF Application Note in your resource list it seems there's a large overlap.
Perhaps most significantly the author presents "novel methods" that combine bootloader binary analysis with constraint-based power glitching in an effort to improve on the results described in "Shaping the Glitch".
While I haven't read the entire 186 pages :D they theorize that using their approach extracting 8kB firmware might only take ~10 hours.
And, most helpfully, they even published their source code under the GPL here: https://github.com/janvdherrewegen/bootl-attacks
So, an interesting adjacent read even if it turns out not to be directly applicable to your situation.
Given I have an interest in & a little experience with firmware reversing my original thought was to maybe provide some hopefully helpful references that more generically related to firmware reversing but more specific is good too, I guess. :)
In terms of reverse engineering tooling, I've used Rizin/Cutter/radare2 previously: https://rizin.re https://cutter.re
On the CAN tooling/info front, you might be interested in taking a look at my "Adequate CAN" list which I originally wrote-up for a client a couple years ago: https://gitlab.com/RancidBacon/adequate-can
Some other probably outdated reverse engineering tooling links of mine: https://web.archive.org/web/20200119074540/http://www.labrad...
In terms of how to approach RE, other than just "getting started & digging in" & learning by doing, I've sometimes found it informative to read other people's firmware reverse engineering write-ups to learn about potentially useful approaches/tools.
Anyway, hopefully some of this is helpful!
[0] I have a tendency to be a little... "verbose" and/or "thorough" (depending on one's POV :) ) so I'll probably split this over a couple of comments, in case I run out of steam while writing and for topic separation.
# Topic 2: Dasher + Guitar Hero style music theory/improvisation practice program
Back "on topic": I remember being quite enamoured/fascinated by dasher when I first encountered it. It's quite a unique interaction paradigm with the constant "forward movement" and "intelligent" pre-filtering/constraint of options with size-based prioritization.
Your suggestion to extend this interaction style for use in the music theory domain immediately appealed to me, as it intersects with some musical things I've been thinking about/playing with recently.
Over the past couple of years I've been playing around with ("rules based" rather than ML) procedural music generation primarily in the context of games.
This has been motivated by a couple of things: partly a procgen project is helpful as a driver for gaining an deeper understanding of music theory which I would like to develop for my own composition/production; and, I'm really interested in exploring ways of providing people with the experience of actually composing/creating their own music--which is something I think many people perceive as something only "musicians"/"composers" can do.
The latter is driven my own music composition/creation/education experience: I learned piano as a kid for about a year until it was "mutually agreed" that if I wasn't going to practice perhaps it would be best to stop. :D But I've always really enjoyed music, particularly electronic/dance/EDM, and wanted to also create it & not just consume it--over the years I played around a tiny amount with creating some but gravitated toward DJing as my primary means of musical expression.
Then a few years ago I started "more seriously" creating tracks with LMMS (a FLOSS DAW https://lmms.io) and while progress was slow it was still nice to be able to enjoy the results.
But I grew frustrated/dissatisfied by the fact that I didn't really know how to add more of a melodic component to my music. (I'm an Anthemic Trance guy from way back. :D )
Over a couple of years after butting my head up against Music Theory a few times and bouncing off again (not unlike my experience with Rust :D ) one day I suddenly somehow "saw" some of the (simplified) Music Theory patterns/rules that I'd not internalised/understood previously.
And then I could add melody to my tracks! :o I mean they weren't masterpieces but it sounded like music! It blew my mind. :)
Not long after I realised something I found quite profound: it felt like music, instrument skills & music theory had only ever been presented to me as a thing that you did so you could play other people's music but I never wanted to play other people's music, I wanted to create my own!
Which then triggered a period of "Why didn't anyone teach me years ago when I was a kid that you could create your own music by starting with a few simple rules & building on them? Here I was "many" years later voluntarily learning about music theory, trying to apply it and even practising scales! :o
Anyway, that experience made me wonder if other people have experienced music & its creation in the same way and what opportunities there might be (particularly within a game/casual context) to provide those people with their first taste of creating music through a "guided" experience of just playing (in both senses of the word).
So, yeah, the "Guitar Dasher"/"Piano Dasher" concept aligns quite nicely with that. :)
Not that anyone asked me. :D
Couple of related things:
* Your suggestion also reminded me of another FLOSS DAW I played around with called Helio which has a "chord tool" (https://docs.helio.fm/tips-and-tricks.html#chord-tool) which appears as a pie-menu pre-populated with chords that fit with the current scale/root. I seem to recall that there are commercial DAWs that also have a similar UI.
* While I'm not particularly happy with its current state (really need to upload the most recent version of the code, which I'm fractionally happier with) here's my first foray into music procgen for a game jam entry (with a "debug quality UI" for controlling the output), if you're interested in checking it out: https://rancidbacon.itch.io/the-conductor
* And from a different angle here's another game jam entry where the concept I was playing with was essentially using music theory concepts as the basis for creating combat interactions/patterns (e.g. "Oh, no, how am I going to harmonize with whatever that was that the boss just played?!") and it all takes place on the "Grand Staff"/"Great Stave": https://rancidbacon.itch.io/stave-off
(Unfortunately as often seems to be the case I ended up spending more time fighting with a Unicode music engraving font/standard than I did writing game play for that last one. :) )
As someone who suffered some severe mobility impairment a few years ago and relied extensively on eye tracking for just over a year, https://precisiongazemouse.org/ (Windows) and https://talonvoice.com/ (multiplatform) are great. In my experience the hardware is already surprisingly good, in that you get accuracy to within an inch or half an inch depending on your training. Rather, it's all about the UX wrapped around it, as a few other comments have raised.
IMO Talon wins* for that by supporting voice recognition and mouth noises (think lip popping), which are less fatiguing than one-eye blinks for common actions like clicking. The creator is active here sometimes.
(* An alternative is to roll your own sort of thing with https://github.com/dictation-toolbox/dragonfly and other tools as I did, but it's a lot more effort)
As someone who suffered some severe mobility impairment a few years ago and relied extensively on eye tracking for just over a year, https://precisiongazemouse.org/ (Windows) and https://talonvoice.com/ (multiplatform) are great. In my experience the hardware is already surprisingly good, in that you get accuracy to within an inch or half an inch depending on your training. Rather, it's all about the UX wrapped around it, as a few other comments have raised.
IMO Talon wins* for that by supporting voice recognition and mouth noises (think lip popping), which are less fatiguing than one-eye blinks for common actions like clicking. The creator is active here sometimes.
(* An alternative is to roll your own sort of thing with https://github.com/dictation-toolbox/dragonfly and other tools as I did, but it's a lot more effort)
Does something like a blink, wink tracker for swiping UI pique your interest? I built a PoC a while back: https://github.com/anupamchugh/BlinkPoseAndSwipeiOSMLKit