itch.io

Ok, so first let me apologize - the last time after downloading the latest version, I didn't actually try binding any keys, but just checked to see if the frequencies had been made accurate.  Based on experiences with the previous versions, I felt accurate frequencies were necessary for my own sanity when debugging.  However, the way the app records peaks now for key presses works really well!  I gave it another test and was able to get an octave's worth of notes to register as separate notes.  So again, I apologize for not giving it a fair shot.  It does seem to be usable for me now.

I'm a little confused why you're brushing this off as a minor bug, though - the Hz aren't just off by an offset, or by some slight inaccuracy - the value could be off by a factor of 10, or probably 100 if you went high enough.  They don't seem to track Hz at all.  Which, fair enough, isn't strictly necessary for binding keys, which is the purpose of the app, but why call them Hz when they're not Hz?  I found it very confusing when trying to make sense of my key bindings.  Obviously I don't know the inner workings of the app, but I would think the APIs would make it easy to match with real Hz?  If it's difficult or impossible for some reason, though, at this point I would recommend simply hiding the Hz data from the user, because they don't really need it to bind keys thanks to the new interface, and it's very confusing to someone trying to set up keys by their actual frequencies.

As far as my personal results and why they've been so confusing, the button presses I've got working have some strange values - the peaks for my octave (starting from the bottom on G3) are 71, 75, 117, 121, 124, 113, 116, 120.  So it starts low, but the value jumps up on the third note, then jumps a little back down on the 6th.  I'm not sure why that is - it could be that my instrument has a messy tone, but tuners don't usually seem to have a problem identifying the notes.  I'll sometimes see the peak that matches up more closely with the previous notes within the spectrum, but it gets superseded by another peak. It's previously caused problems when these ranges start to overlap, so that multiple notes are trying to press the same key, but the new multi-peak recording interface has somewhat resolved that problem.  At this point I guess I should just treat it as a black box and not look inside, but the engineer in me wants to figure out why these values are so unexpected.

It's not an issue of precision - the issue is that when I play an 800Hz sound the app says it's 121Hz (for example).  Unless it's something about my hardware, which seems really unlikely (I've tried multiple mics and instruments).  When I use this: https://www.szynalski.com/tone-generator/ to play a 440Hz tone, for example, the app is saying 100Hz.  Try it yourself - are you getting a different result?

EDIT: looking at Lobos' DS1 playthrough, the last time I see him retuning the app, all the frequencies he's got buttons assigned to are between 40Hz and 150Hz or so, which is a similar range to what I'm seeing, and doesn't really make sense.  40-150Hz would be a range of less than 2 octaves and he's playing a whole guitar (and those frequencies are way lower than what a guitar plays within).  So I think it's a universal problem, he just might not be aware of what frequencies he should be expecting.

Tried this version and it still has the same bug with Hz not matching what is played.  Based on plotting out the data, it seems like maybe there's an extra square root or log somewhere in the calculations?  Or maybe something needs to be squared?  Unfortunately I'm finding the app unusable because of this bug.  With the bug fixed it would be trivial to convert to note pitches, which would be a nice bonus to solving it.

Hey, I posted this in the previous version but you might have missed it - I think there's a math error in your frequency calculations.  Using a pure tone generator (https://www.szynalski.com/tone-generator/), the frequencies the app "hears" isn't matching what's being played.  For example, playing 100Hz is heard as 48Hz, and playing 800Hz is heard as 121 Hz.  

I assume it should be a fairly easy fix, but do lmk if you want any help - I've got Unity and C# experience, and a fair amount of free time atm.  Plus a friend who's fairly expert on this frequency/signal stuff who I can bug for help lol.

Fair enough, thanks for the work you're putting in on this.  Would it be possible for me to look at the source code?  I understand if you don't want me to be able to change anything, but I'd be curious to take a look and see what you're doing so far, to see if I can figure out how to make it work with notes.

EDIT: talked to my friend who's more educated in frequencies than I am, and the ones being shown don't match up with what they "ought" to be.  Theoretically using the peak should work fine, but the peak isn't matching what is expected (i.e. A4=440Hz), even using sample tones.

I did some testing and I think the problem may be as simple as some bad math - I tested pure tones and the spectrum looked reasonable, but the Hz number itself was off.  Here are all the Hz I tested - what was played on the left, and what was heard by AAI on the right:

100 = 48.16
150 = 61.17
200 = 71.23
250 - 80.27
300 = 86.37
350 = 91.52
400 = 97.03
450 = 100.78
500 = 104.30
550 = 107.46
600 = 111.09
650 = 113.67
700 = 116.13
750 = 118.36
800 = 121.05

I notice two things - first that the "heard" number is always lower, and that it keeps getting further and further off.  50Hz played difference at low frequencies makes a 13Hz heard difference, but at the top end it's only a 3Hz heard difference.  So I'm thinking there must be some math error with how you're converting frequencies to a Hz number?  If the number is right then it should be easy to convert to a note just using the A4=440 table.

Hmm, are you using C#?  I could try looking around for an API.  I've done some work with Unity in the past so I might be able to help in some capacity.

Assuming that's impossible, though, the problem I'm running into is that it's hard to find unique frequencies for each notes.  Each frequency is often shared between some number of notes when I play them, so it's pretty tedious trial and error, made worse by how difficult it is to identify frequencies when it keeps flipping between the highest peak.  What if, instead of displaying only the current highest peak, it displayed multiple (like the top 5)?  That seems like it'd be pretty doable with what you've already got so far, and would make it a lot easier to identify the different frequencies in each note.  If possible, it'd also be cool to order the frequencies by their frequency number, instead of by highest peak, so that they don't flip-flop whenever one peak gets slightly higher than the other, since it can be really hard to read on the current display when two frequencies are at similar peaks.

Hey, having some difficulty with how the app processes audio - the hertz that it's reading doesn't match what it "should" be.  I.e. when I play a G3, it says 120Hz.  When I play a C4, it's still 120 Hz but sometimes it waffles between 100 and 120.  Other notes have different frequencies they waffle between but 120Hz is often one of them.  I'm playing a hurdy gurdy which can have a bit of a messy sound, but my phone's tuner app doesn't have much trouble identifying the notes I'm playing, whereas when I add an entry on Abject and set it to whatever the pitch is supposed to be (i.e. 440 for A4) it doesn't pick it up at all.

I guess I can just trial-and-error each note to figure out what frequency Abject thinks each note is, but it'd sure be a lot easier if it picked up notes as the notes they're supposed to be.  Maybe I'm missing something but I feel like a note => button seems a lot easier to use then a frequency => button interface.

EDIT: I did some additional testing using stock (viola) sounds, and it had the same issues.  The Hz reading flickered around a lot, and the numbers didn't seem to correspond whatsoever with the actual note being played.  I'm not sure what it's actually picking up?  But one maybe easier fix would be to change the spectrum analyzer - right now it shows me a nice graphic of how many different frequencies it's picking up, but I can't actually tell which frequencies those are and use them, unless I can see them on the Hz display above, which only seems to display whichever is currently the loudest and can be very hard to read when it's flicking back and forth between frequencies.  If I could at least see what frequencies it's hearing, it'd be a lot easier to find frequencies that I can use.

Ok I've been fiddling and found a workaround - with AutoHotKey I can pipe the key output from AAI to do whatever script I want.  So I've got it set to move the mouse by outputting a "j" and then AHK moves the mouse when the j key is pressed.  Bam.  Camera control achieved.

I'm having a little difficulty with making nice, fluid motion, though - I was hoping I could turn right as long as I was playing a certain note, for example.  And I've got a script that, so long as I hold "j", the mouse continues to slide right at a constant rate.  But when I try to use AAI to send a "j" to move the mouse, it seems to only send and release one "j" instead of holding it down, even though I'm using the "holded" type, and the mouse stops moving.  Is there a way to "hold" a button down for as long as the corresponding note is being played?  Thanks!

EDIT: I think I fixed it - I think it was a problem with my script and not the app.  Camera control is starting to feel pretty smooth!  This is really cool!

I'm trying to figure out a way to bind camera controls with this (to play subnautica) - I get why assigning mouse movements would be difficult, but maybe as a workaround it could output using a game controller?  I don't seem to be able to assign any pitches to game controller outputs (while selecting the input, pressing buttons on my controller does nothing), but if that was added as a feature, it'd basically eliminate the need to control the mouse for any game that can use a game controller.  Is this a potential option?