an idea:
since Visualizer recognizes a chord, would it be possible to isolate and get the fundamental note on a standard V/oct patch point?
I’m not asking for the lowest note because I know it recognizes inversions as well
That’s an interesting idea. I think I can do that.
1 Like
Thinking about it - I have that kicking around as the pitch moved into the octave above middle C. Would you want that pitch, the absolute pitch, normalized to 0 = first note of scale, or ???
btw, I’ve been working on getting the spacing better in the score, so I won’t post a bug fix until that stuff is working.
2 Likes
I would say standard
0V = C4 = 261.63Hz
1V = C5
and so on
I just put up a new version of visualizer. Mainly the notation tries harder not to overlap accidentals.
Also fixed bugs reported in the last one, and added a new feature: it outputs the root note.
2 Likes
I like your new Visualizer module 
1 Like
When I thought “I’ll just put up some music notation, like in Harmony” I totally did not realize how much more work there would be with enharmonics and visual collisions of glyphs!
1 Like
it works VERY well until we reach the 6th/7th accidental, very nice job!
removing cable bug and overlapping accidentals looks fine to me now
the unicode flat symbol is still missing, I hope it could be implemented in a future versione, just because it is confusing to read “E-” on the display while we are actually getting “E flat” (much confusing for jazz or american musicians who are much prone to chordal symbol usage than me for sure)
the idea of “vaild” gate if root is recognized as “correct” is very handy (much more than have it in the context menu, which would be not accessible). let me say that this function is MUCH appreciated, it’s the icing on the cake for ambient music or in a sort of controlled-but-generative patch, I can’t thank you so much!
p.s. I don’t know if it be considered a bug, but changing the option flats/sharps in the context menu doesn’t refresh the display:
load a new instance of Visualizer
feed it C Eb Gb
if you change the option to “flats” in the context menu nothing happens, but if you take away the V/Oct cable and re-connect it, it shows the chord as expected
By the way - here’s the setup I use for testing Visualizer. Nothing special about it, I use Harmony II because:
- I’m familiar with it.
- It makes it easy for me to add more notes.
- I can use a CV to sweep up and down and octave easily.
Thanks for the quick feedback! I’ll try to respond to all this.
-
It is a bug/mistake that the display does not update when you change the sharp/flat setting. It does change on Harmony, I think. I’ll add that next time.
-
I know of no font that has both letters (A through G) and musical symbols (sharp and flat). For that reason, and other reasons, I don’t plan on changing the text UI that uses “-” instead of a flat symbol.
-
The display of C Diminished - It’s notated as B sharp diminished, but It’s identified as “C Diminished”. Well, It’s intended, don’t know if it’s optimal? I personally tend to call that chord C diminished, but I don’t think anyone would notate it as “C, D#, A#”. In any case, the code is structured such that the notation and the identifier text don’t know about each other. Yes, they both know about the “sharps&flats” preference, but they interpret it different ways.
I’m not sure I would want to make those two agree, but I do know it would be a lot of work.
Also, while that preference does tell me to use D sharp or E flat, it does not every tell me to use B sharp or E sharp. Those are things I only do in the score window.
- Somewhat independently - I’m sure you’ve noticed that the older version always picked sharps (or flats) for notation, and the resulting enharmonic spelling was not very good. Now that setting is just a suggestion. You may have noticed that there are even cases where I mix sharps and flats on the notation.
Now, it’s arguable that I pay too much attention to that setting, or that I should perhaps discourage spelling C as B sharp. Even if sharps are preferred, the spelling of of C, E flat, G flat might be preferred to the spelling B sharp, D sharp, F sharp? I could adjust the algorithm, if so.
not the person you were addressing, but the rule of thumb is triads are arrangements of thirds
C D# is an augmented second, a useful thing, but not used in triad spelling unless it is spelled B# D #F#, which are thirds
yes we know enharmonically they are the same, but the namings makes it easier to grasp not more confusing hopefully
And technically there are “keys” with sharp and flats, like when I use F# in G minor which has Bb also. G harmonic minor
Yes, I know those things. tx. ( I think the module knows those things, too. If not it’s a bug ).
1 Like
if easy, it’s not a bad idea, just to be done for B#/C and E#/F
@ale47p yeah. I’ll write down what the current algorithm is, so you can advise. tx. And, yes, I know that those are the only two white keys that don’t have a black key in between them 
tx again!
1 Like
Here’s the current enharmonic spelling algorithm:
For recognized chords, it “knows” that (for example) in the C Major chord C3 E2 G3 that the E is in the role of the third, even though it is inverted. For non-recognized chords it would know that C3 E3 is a third, but it wouldn’t know anything special about C3 E2.
The only note spelling it knows about are default for the scale, sharp, flat, and natural. It does not know about double sharps and double flats. It does know that C is B sharp.
So, to generate the spelling of a chord.
It considers every spelling and computes a penalty for that spelling. This is 2 to the n spellings, where n is the number of notes.
It picks the spelling with the smallest penalty.
The penalty is currently: 10 for each third that is not separated by two leger lines (for example, C sharp and F are a third apart, but three leger lines, so would have a penalty of 10 for this. C sharp and E sharp would not have that “bad third” penalty.
There is a penalty of 3 for each time there are two notes on the same line. For example, C and C sharp in the same octave - it would prefer C and D flat.
There is a penalty of 1 for each accidental that needs to be drawn, including naturals.
There is a penalty of 1 for each accidental that it not in the current preference. So in D Major, by default it’s a sharp key, so F sharp would be preferred to G flat.
1 Like
You may be better off using “b” for a flat symbol or absolutely anything else, instead of a “-” as there is a fair amount of usage of minus for minor chords. Of particular note which has widespread usage is the jazz Real book:
2 Likes
lower case b is a pretty good idea. tx.
4 Likes
I posted a new test release:
- Gate input now works correctly.
- Score display updates when sharps&flats preference updated.
- Identified chord name follows sharps&flats preference.
It’s close to being ready for the library. I’m considering adding some features:
- Improve enharmonic spelling on score display when there is a fifth with no thirds in between.
- Reduce the delay to one sample when the output is patched.
- Identify a chord as a 7th when the 5th is missing (i.e. 1,3,7).
There are probably still bugs to be found. Especially now that the scrore display is usually much better, there are probably still some bad cases.
Release is here:
1 Like
I’m going to have to give this a try. Even though I can read music I do almost everything by eye and ear. I grew up playing cello and chords confuse me.