Announcing: Squinkytronix modules

[Squinky]

I’ve got a couple of new modules I’ve been fooling with for a bit. There are test builds available.

The new “line” is called “Squinkytronix”. You might notice the name is similar to “Squinky Labs”. Well, it’s still me, but doing slightly different things. I will try to avoid doing any DSP modules, so the dreaded “A” word shouldn’t come up.

One of the modules is called “Harmony”. You might call it an intelligent chord generator. Although it’s not that intelligent. It picks the chord voicings, including doubling and inversion, to generate rudimentary voice leading that follows as many rules as it can and that it knows about (whichever is smaller).

It displays the resulting four part harmony in what I think is pretty nice looking standard music notations. But that’s just eye candy, you don’t need to read music to use this module. The CV outputs are where the action is.

The other module is called “Arpeggiator”, which is what it is. It has a good number of arpeggiation modes, and some extra controls to control the rhythmic repetitions. And lots of CV control.

Neither of these modules is ready for release. I’m hoping some adventurous people will try them out and suggest some cool changes.

Harmony, in particular, could use more features. People who do know old fashioned music theory will be in a good place to understand this and suggest some features, but other too.

The current panel designs are just hacking around, and will not be final. I don’t really know what these will look like, but they will be “dark” and won’t tend to have small blue knobs.

There are mac, win, and linux builds available for download. The modules do have skeletal documentation, too, on the context menu in the expected place.

The manual for Harmony does list the voice leading rules that it knows about, for those who are interested.

You can find the downloads here: Release v2.0.0 · squinkylabs/SqHarmony · GitHub

And there are links to the manuals here: GitHub - squinkylabs/SqHarmony at b2

[Patheros (Andrew Hanson (Path Set))]

Harmony is supper cool.

Arpeggiator I’ve got a question:

I’m not sure I understand what length does, or what length of 0 does. The manual says “If length is zero it’s not limited” so I would expect at 0 or 12 the result would be the same, but its not. (Look at the red line on the scope)

Also I noticed when the clock and gate inputs are the hooked up to the same clock, nothing comes out. I would expect at least one note to come out in that case, but I don’t use a lot of Arpeggiators.

Also what is the dreaded “A” word?

[dag2099]

@Patheros

Also what is the dreaded “A” word?

“Aliasing”. Mr Squinky has an…interest in it.

[Squinky]

@Patheros

so I would expect at 0 or 12 the result would be the same

I would like to make a diagram to make it a little more clear - it isn’t clear at all. But 0 is not the same as 12. 12 would mean that if you played in 13 notes, only the most recent 12 would be kept. but 0 would keep all notes. So the length is the number of notes in the memory, with 0 being the magical “as many as you played”.

I will admit that “length” is perhaps the most useless / subtle option in there.

[Squinky]

@dag2099

“Aliasing”. Mr Squinky has an…interest in it.

yes, @dag2099 is correct!

[Squinky]

@Patheros

Also I noticed when the clock and gate inputs are the hooked up to the same clock, nothing comes out.

I’ll have to try that. Not immediately sure what should come out, but nothing does seem odd. tx.

… that said, in a patch like that I might run the output of the chord generator into a merge (to make it poly), then run that into the CV of the apreggiator.

clock into gate will be a problem, because every time the gate goes low, the notes all go away. Unless your turn on the hold feature.

[Squinky]

The reason the “TL:DR” path is in the manual is that is shows a super simple patch that is typicall for this kind of gizmo. usually the “notes” from the keyboard will be hold much longer than a single clock cycle:

[Squinky]

If you make a patch like that and hold down a chord on a keyboard and run a reasonable fast clock you will hear a very typical application. Of course I hope a creative person can do better But at least this way you can hear what all the different modes do.

[Squinky]

@Patheros

Harmony is supper cool

Thanks! I think Harmony is the more unusual / cool module too. I think after I made that I made arpeggiator thinking “what can I do to make the output more fun”. So I kind of fell into making that. There are already a bunch of arps in VCV, so there’s very little super unique in there. But I hope it’s got enough fun features in a compact package that people will like it.

[Ahornberg]

I knew you would come up with something new.

[LarsBjerregaard]

Sounds/looks very cool Bruce!

[Schabbes]

I really like the “Beats” feature, but was expecting this to be the “Length”

A problem I encountered is that when connecting it to Entrian Timeline, which always sends a higher polyphony count than what is actually played, it doesn’t properly recognice the notes being played and just repeats one note.

Another feature that I think is great for an arpeggiator is if you can determine the order of notes yourself - don’t know if this would be an option for you.

[browneditor]

Proper

[Squinky]

@Ahornberg

I knew you would come up with something new

Thanks! Although, as the manual says, “Harmony” is not exactly new, I wrote it in 1991

[chaircrusher]

One idea for Harmony you can steal from VCV Chords: The context menu item “Polyphonic outputs channels 1-N”

I generally turn this on and use the 4th output to get the chord out but I can think of use cases for the general 1-N behavior. More useful would be if connecting an output outputs all previous unconnected voices.

In other words, connecting outputs 2 & 4 would give you the first 2 voices on 2 and the second 2 on 4. Or if you connect 3 and 4, 3 has the first 3 voices and 4 would have one voices.

In writing this, I notice that it’s really difficult to describe this stuff without getting tangled in the language.

[Squinky]

Yes, Beats and Length are perhaps not the best names for these controls, and of the two I think “Beats” is much more useful. I think “Length” might be important if you are using the hold features, but I need to play with it more, and get more feedback from people like you.

As far as determining the order, there is of course the “order played” mode, which may be what you want? As far as being able to edit the order or do something more like that… don’t know. I had some other idea for this thing (algorithmic mutations, for one) but eventually realized they don’t belong in this module.

It’s a bit of an odd duck, actually. As a “classic” arpeggiator, it’s definitely easier to hear what it’s up to if you “play it from a keyboard”. But I hope it will also be useful in more machine driven patches. We may discover the features need some tweaking to make it really good for that.

[Squinky]

@Schabbes

Entrian Timeline

I’ll look into that. It shouldn’t mind a high polyphony count, as it gets its notes from the gate input. For example, the “TL;DR” patch takes its input from the MIDI-CV modules, and recommends a high polyphony, but it still works fine. I’ll need to look at Entrian and see what’s up.

[Squinky]

haha - yeah, I had to read that a couple of times. So basically the next connected output gets itself as well as the previous unconnected output? Oh, and of course now al 4 outputs are monophonic, but with that scheme would need to be 1…4 channels, depending. Cools idea (thanks @Vortico ).

I always wanted to add a simple 4 vx poly output, but with this proposal you would get that just by patching vx 4 only.

If I were to do that, do you think it should always be enabled? Enabled by default, but defeatable by context menu?

[chaircrusher]

I think there’s a bug in the Arpeggiator. I’d just do a pull request, but I don’t know what you intend here: In Arpeggiator.h, in Arpeggiator::process, it looks like there should be curly braces around the ‘else’ part. This was actually a warning from g++ because I turn on -Wall

if (monoGates) {
    // for mono gates, just look at gate[0], but send to to all cv channels
    gateDelay.process(TBase::inputs[GATE_INPUT], gates);
    bool gate = gateDelay.getGate(0);
    if (gate != lastGate[0]) {
        lastGate[0] = gate;
        for (int ch = 0; ch < cvs; ++ch) {
            onGateChange(ch, gate);
        }
    }
} else
    gateDelay.process(TBase::inputs[GATE_INPUT], gates);
    for (int ch = 0; ch < gates; ++ch) {
        //bool gate = TBase::inputs[GATE_INPUT].getVoltage(ch);
        bool gate = gateDelay.getGate(ch);
        if (gate != lastGate[ch]) {
            lastGate[ch] = gate;
            onGateChange(ch, gate);
        }
    }

There’s also a place where you increment a boolean instead of assigning true which generates a warning, because arithmetic on bool types is deprecated.

— a/notes/HarmonySong.cpp +++ b/notes/HarmonySong.cpp @@ -41,7 +41,7 @@ HarmonySong::HarmonySong(const Options& options, const int* pS) : chordManager(o // TRACE(“at start of const, size = %d\n”, chords_ar.size()); for (i = 0, done = false; !done; i++) { if (pS[i] == 0) {

•        done++;
  

•        done = true;
     } else {
         auto ch = std::make_shared<RankedChord>(chordManager, pS[i]);
         chords.push_back(ch);
  

[Squinky]

@chaircrusher

I think there’s a bug in the Arpeggiator.

Oof! Yeah, I put in the “mono gate” very recently, and obviously made a terrible mistake! I’ll go fix that ASAP (after breakfast - it’s pretty early here in PST). In general I’m happy to take PRs for bug fixes typo fixes, etc… fwiw never had a PR for a new “feature”. That could be tricky, better to discuss something like in advance.

Wow, that might explain some of the problems people are having. Yikes!