uclock 96PPQN query/help

[houtson]

I'm building a custom arpeggiator and hoping to use your uclock library and a Teensy 4.

I'm looking to operate the arp at 96PPQN but when I use the library with the example setups the ClockOut96PPQN callback seems to run at 24PPQN (so everything runs slow on my arp).

I also note the examples all send out midi beat clock from the ClockOut96PPQN callback but I understand beat clock is 24PPQN - I thought you'd need to send a beat clock every 4 96PPQN ticks?

I'm fairly new to this so may not have picked up things correctly so apologies if wasting your time.

Thanks for sharing your library, really appreciate the effort you have put into it. Paul

[midilab]

Hi @houtson

Actually you got a point here, and for the first time after long i've realise that the naming convetion of library API is wrong, and the actual resolution of the library is indeed 24PPQN o_O.

So first of all thank you for point out. I have a old TODO task to support higher resolutions, so i think this is a good time to bring this task to the table and rewrite it first to actually supports 96ppqn and also create a new 24PPQN callback for sync stuffs.

I'll let you know here when i get a new release with the mentioned fixes.

[houtson]

Thanks for the quick response, that's helpful to know - I thought I was going daft! Would be really keen to have 96PPQN so any help on testing or otherwise please just shout out - the basis of the library is great.

[midilab]

So i created a branch to finish the v2 release of uClock, with support for new high resolutions!

https://github.com/midilab/uClock/tree/v2-release

If you could make some tests will be great! i still need to port the shuffle support to dinamicly PPQN... but from here weŕe going to v2 release of library.

I have changed the README with notes for the refactor API, any questions please you can raise it here, i will re-open this issue so we can work thru here.

Once again thanks for the contributions with the project.

[houtson]

Thanks for the quick turnaround - I had a quick test of the new branch and works well for me. Only really basic testing but everything running as expected.

A question related to external clocking and this new version - will external clocking expect a clock at the setPPQN rate or at a different rate? I've not implemented it but it is next on my list, ideally I'd like to be able to (externally) clock it at a different rate although I guess I could just create another instance if it follow setPPQN.

A couple of really minor typos in readme Resolutions: _'set youw own resolution for your clock needs

PPQN_24 24 Pulses Per Quarter Note PPQN_48 48 Pulses Per Quarter Note PPQN_96 96 Pulses Per Quarter Note PPQN_384 384 Pulses Per Quarter Note PPQN_480 480 Pulses Per Quarter Note PPQN_960 96 Pulses Per Quarter Note'_

[vanzuiden]

Happy new year everyone!

Nice to see this development going on. I will try to test this branch over the weekend.

I was just about to open a discussion about the resolution of the clockMe function. It currently expects to be triggered with a 24ppqn clock signal, as per the midi clock specification. I'm syncing a device running uClock with external eurorack modules, and not all of them are able to output a 24ppqn resolution clock.

It would be very powerful to be able to externally sync uClock with lower resolution signals, and to be able to upscale this to high resolution clocks to be used within our devices.

[midilab]

@houtson

A question related to external clocking and this new version - will external clocking expect a clock at the setPPQN rate or at a different rate? I've not implemented it but it is next on my list, ideally I'd like to be able to (externally) clock it at a different rate although I guess I could just create another instance if it follow setPPQN.

The most accepted and used clock base on the market and also as midi standard definitions is 24PPQN. So the clock still runs on 24PPQN and the real deal with this library is the external sync mechanism wich is also based on 24PPQN, this will be tricky to port to other resolutions but its possible, since there are some voodo things going on with phase factor and PLLX, it needs some real tests to adjust greatly, but anyway i have this on my TODO list too, create support also for sync side of library to receive different resolutions.

@vanzuiden

It would be very powerful to be able to externally sync uClock with lower resolution signals, and to be able to upscale this to high resolution clocks to be used within our devices.

Sure thing! like i said, its on Roadmap, but since you're dealing with a lots of eurorack you could tell me the needs you have nowdays in terms of clock resolutions for sync avaliable on eurorack market...

i've only tested with 96PPQN so far, but you can go high as 960PPQN here for the internal clock resolution, but keep in mind that the higher the resolution more CPU consumption will happen.

[midilab]

Shuffle revised, now looks way more musical, testing on simple shuffle schema, even notes shifted forward (N), can be shifted backwrads too using negative values, the value is in pulses, for 96PPQN there are 24 pulse in between so you can move step forward or backward. here is a example of the shuffle in action on aciduino sequencer based on MPC60 shuffle signature and 909s...

struct ShuffleSignature : PageComponent {

  // MPC60 groove signatures?
  // Same as 909
  uint8_t current_shuffle = 0;
  uint8_t template_size = 2;
  int8_t shuffle_50[2] = {0, 0};
  int8_t shuffle_54[2] = {0, 2};
  int8_t shuffle_58[2] = {0, 4};
  int8_t shuffle_62[2] = {0, 6};
  int8_t shuffle_66[2] = {0, 8};
  int8_t shuffle_71[2] = {0, 10};
  int8_t shuffle_75[2] = {0, 12};

  String shuffle_name[7] = {"50%", "54%", "58%", "62%", "66%", "71%", "75%"};

  int8_t* shuffle_templates[7] = {shuffle_50, shuffle_54, shuffle_58, shuffle_62, shuffle_66, shuffle_71, shuffle_75};

  void view() {
    genericOptionView("sig.", shuffle_name[current_shuffle], line, col, selected);
  }

  void change(int16_t data) {
    current_shuffle = parseData(data, 0, 6, current_shuffle);
    // uClock shuffle
    uClock.setShuffleTemplate(shuffle_templates[current_shuffle], template_size);
  }

} shuffleSignatureComponent;

[vanzuiden]

Sure thing! like i said, its on Roadmap, but since you're dealing with a lots of eurorack you could tell me the needs you have nowdays in terms of clock resolutions for sync avaliable on eurorack market...

Most clocking modules that came out in the last 5 - 7 years or so support a 1/96 (24PPQN) clock, such as ALM New & Pro Workout, Squarp Hermod+, Erica Drum Sequencer and also the Beatstep Pro as external sequencer.

Some older modules that offer clocking capabilities output lower resolutions, like the original Squarp Hermod outputs a 1/32 (8PPQN) clock for its highest resolution.

Then there are the more classic 'step per tick'-style sequencer modules that do 1/16 (4PPQN) resolution. An example of this is the Intellijel Metropolis but there are many.

A lower resolution is also used when you're not generating a clock with classic (BPM style) clocking modules, but more freestyle/random modules like the Intellijel Random Noise Tools, Make Noise Wogglebug, Instruo ochd + expander, etc. For more 'ambient'-style things you'd like to run these at slower speeds.

[houtson]

So the clock still runs on 24PPQN and the real deal with this library is the external sync mechanism wich is also based on 24PPQN

What I'm looking to do is to have a 96ppqn callback for the Arp plus external sync at 24ppqn (for external midi and dinsync syncing) - by the sound of it I should be able to do that with this new version of the library, cheers Paul

[midilab]

great guys thanks for the tests and feedbacks! the branch was merged into main and deleted, so you can take from main branch... soon i will prepare a release for platformIO and arduino.