profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/paradox460/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Jeff S paradox460 San Francisco, CA

paradox460/.dotfiles 7

Config files and whatnot

paradox460/cinch-reddit 2

A reddit plugin for the cinch irc bot framework

paradox460/flatland 2

Flatland is a simple theme and accompanying color scheme for Sublime Text 2.

paradox460/github_slack_spammer 1

A utility for taking open PRs that need approvals, and spamming them into a slack channel.

paradox460/4chan-x 0

Adds various features to 4chan.

paradox460/absinthe 0

The GraphQL toolkit for Elixir

paradox460/AndroidBot 0

A variant of Clippy_Office_Asst for /r/androidquestions

paradox460/asdf-nim 0

nim plugin for the asdf version manager

push eventparadox460/.dotfiles

Jeff Sandberg

commit sha ff4546b2be24af418a32db8fe4987f83b386abc5

Tweak mpv input configs Note that this commit probably has some issues with the included scripts. I've started moving the scripts to their own repo, but haven't finished the move here

view details

Jeff Sandberg

commit sha d3054eee2509c8c5ae3263c78671420702292a3b

Add skhdrc keybindings, fix chrome tab outliner

view details

push time in a day

startednoteflakes/lyp

started time in a day

delete branch paradox460/VSLilyPond

delete branch : feature/restart-midi-input-on-port-change

delete time in 6 days

delete branch paradox460/VSLilyPond

delete branch : bugfix/handle-running-status-keyup-properly

delete time in 6 days

delete branch paradox460/VSLilyPond

delete branch : bugfix/calculate-midi-status-type-properly

delete time in 6 days

startedlhl2617/VSLilyPond

started time in 13 days

pull request commentlhl2617/VSLilyPond

Handle keyUp status in running status mode

How on earth did that happen. Very strange

paradox460

comment created time in 13 days

pull request commentlhl2617/VSLilyPond

Handle keyUp status in running status mode

Awesome, thank you very much.

Sorry for the back-and-forth on the meaning of a Note On with velocity 0. It was buried in a passage of the spec I skipped over the first time around.

Also, you might want to check your release system, I noticed that your repo showed 1.7, but VSC won't update past 1.6.5. Is it stuck in an approval pending phase or something?

paradox460

comment created time in 15 days

PR opened o4x/base16-tomorrow-vscode

Add bracket colorization support

Add support for the new bracket colorizer, built into VSCode 1.60 (August 2021)

This can be turned on via the editor.bracketPairColorization.enabled": true setting, and is off by default

+8 -1

0 comment

1 changed file

pr created time in 15 days

push eventparadox460/base16-tomorrow-vscode

Jeff Sandberg

commit sha 0a47937dba349899e58461d61ae2a4ba87714784

Add bracket colorization support Add support for the new bracket colorizer, built into VSCode 1.60 (August 2021) This can be turned on via the `editor.bracketPairColorization.enabled": true` setting, and is off by default

view details

push time in 15 days

fork paradox460/base16-tomorrow-vscode

A base16 color theme styled to look like Atom's Base16 Tomorrow 🏳‍🌈

fork in 15 days

startedjazz-soft/JZZ

started time in 17 days

PR opened lhl2617/VSLilyPond

Handle keyUp status in running status mode

According to the MIDI spec, a keyDown with a velocity of 0 is equivalent to a keyUp status. This is how the code previously worked, prior to 71300a0.

The MIDI spec section in question:

Running Status is especially helpful when sending long strings of Note On/Off messages, where "Note On with Velocity of 0" is used for Note Off.

This commit reintroduces a check for that, while preserving the newer (as of 71300a0) status checks. That way, both keyUp AND keyDowns with 0 velocity are registered as keyUps

Interestingly enough, JZZ had issues with running status last year, but they have fixed them https://github.com/jazz-soft/JZZ/issues/26. Provided this holds true, we don't have to worry about maintaining current status for RS mode.

+3 -1

0 comment

1 changed file

pr created time in 17 days

PR opened lhl2617/VSLilyPond

Calculate the midi status type regardless of channel

The previous implementation (71300a0) used 0x80 and 0x90 comparisons directly, which meant any midi device set to use a different channel would not be seen by the plugin.

This is because a statusByte is defined as two sets of nibbles.

0x91 = 1001 0001
         9    1

    1001 0001
    Type Channel

The first nibble is what we care about, the type of message. The second is the channel, from 0 to 15.

So by using a simple bitmask, we can discard the channel information, and our checks continue to work

+1 -1

0 comment

1 changed file

pr created time in 17 days

PR opened lhl2617/VSLilyPond

Restart midi input on port change

In the current implementation, if you start a MIDI input session, and then change the device/port, your existing MIDI session will continue with the old device/port.

This ends that session and immediately starts a new one, effectively "restarting it."

JZZ was unclear if their package allows for changing a port while a read callback is running. Some other WebMIDI systems, such as webmidi.js, do allow for this.

+9 -0

0 comment

1 changed file

pr created time in 17 days

delete branch paradox460/VSLilyPond

delete branch : bugfix/use-midi-status-for-keyup

delete time in 19 days

PR opened lhl2617/VSLilyPond

Use the MIDI status byte to determine keyDown

The MIDI status byte is present in every MIDI message, and indicates what the message actually is. For a keyDown message, the byte is 0x90.

Many keyboards emit non-zero velocities on key up, and some are even variable based on the key return speed.

This commit changes both the MIDI message processor to only look at messages with a keycode of 0x80 (keyUp) or 0x90 (keyDown), as well as ensuring the previous note range clamp is in effect. It fixes #341.

Furthermore, it fixes a class of issues where other control surface inputs were being captured as notes.

+10 -5

0 comment

1 changed file

pr created time in 21 days

create barnchparadox460/VSLilyPond

branch : bugfix/use-midi-status-for-keyup

created branch time in 21 days

issue commentlhl2617/VSLilyPond

MIDI input is not debounced

Investigating a bit more, it looks like the velocity on key release is 64

Screenshot 2021-09-03 at 20 23 40@2x

paradox460

comment created time in 21 days

issue openedlhl2617/VSLilyPond

MIDI input is not debounced

I am using a KORG microKEY AIR (bluetooth 25key midi keyboard) on MacOS 10.15.7, and when attempting to input notes, I get a "double note" effect. Pressing the key gets one note entered into the document, but releasing it gets the same note.

Additionally, there is some carry-over from previously entered notes.

Screenshot 2021-09-03 at 15 27 12

created time in 21 days

startedslab/delta-elixir

started time in a month

push eventparadox460/mpv-scripts

Jeff Sandberg

commit sha 0000000ad43b743d50eb9804176a19768be4c79b

Fix boolean arg parsing in writename.lua Not a perfect fix, but should cover all config file variations. Now, to set a param to the script-message-to command, it _must_ be a `true` to be true, all other strings are falsey.

view details

push time in a month

push eventparadox460/mpv-scripts

Jeff Sandberg

commit sha 000000009f079c78fb22278625eb128c7c8b37c5

Add recommended scripts/keys for writeedits

view details

push time in a month

GollumEvent

create barnchparadox460/mpv-scripts

branch : master

created branch time in a month

created repositoryparadox460/mpv-scripts

created time in a month