News from the MIDIpal code sweatshop

I’ve rewritten the MIDIpal clocking system so that the “note clocking” option is now a first-class citizen.

All apps which had an internal/external clock setting now have a “not” setting for note clocking (arpeggiator, sequencer, delay…). When this setting is in use, external clock messages are discarded - but start/stop messages are still taken into account. I think this is the only correct way of implementing this feature.

Now the problem: the code changes I have made are 1/ quite ugly because they are clearly pushing the boundary of the existing architecture ; 2/ touching absolutely everything. So in a way, this change is worthless because it invalidates the 10000hrs of collective validation the previous code had.

Please test. Not just the features that interest you but everything you can. It would be nice to post here about which parts of the firmware you tested!

whoah, thank you, it’s getting better and better!

as i demonstrated yesterday, this earlier version was already working quite well - if you have a drum machine that can be prevented from transmitting midi clock. now this sounds even better.

and i solemly swear that i’m going to test it as soon as i can. trouble is, i cannot say when i will find the time. i’m awfully busy at work. plus from tomorrow on, i’ll have some guests over from rome. but i will try it eventually and post about it here…

so if i understand it correctly, the entire note as clock thing is now not a global setting anymore, but one that can be set per app?

does this also happen to take care of the slight note length awkwardness of that earlier 1.4a version? what i mean is that that version was taking the note = clock tick so literally that notes would always stay on until the next clock note was received. which is why i used sounds with ar envelopes in those two demo clips instead of ones with full adsr envelopes (setting the sustain to 0) - which worked fine. with adsr envelopes otoh, you needed to either live with very long notes or double the clock note division with respect to the note lenght (i.e. use 1/32 clock notes to sequence 1/16 notes) and use two clock notes per sequencer note - one for note on and one for note off.

perhaps this version takes its note lenght from the clock notes’? (iirc, that is how the actual 101 does it, isn’t it? clock pulse lenght = note gate lenth)

> the entire note as clock thing is now not a global setting anymore, but one that can be set per app?

The channel and note number of the “clock note” are still global settings. What determines whether they are active or not is now the setting of the clk parameter - which is set on a per-app basis.

> does this also happen to take care of the slight note length awkwardness of that earlier 1.4a version?

No. There is absolutely no solution for that. The rules of the game are not “use a note message to step through the sequence” but “use a note message to advance the sequencer clock by N ticks”. This is how things used to work with the SH-101 and 808 setup.

There is NO WAY I am going to increase the complexity of each app to add special tweaks and semantics for taking care of this.

well, it’s not really a problem as such, anyway.
it just came unexpected when i first tried it, compared to what i remembered from the 101.
but yours is a perfectly valid solution.
people can easily deal with it by either using ar envelopes or using two clock notes per sequencer note…

so i’m really looking forward to testing this new version!

The 101 sequencer does not have any implementation of gate length. The note stops just before a new one is played, or when there is a rest. You have to fake it with envelope decay.

ah ok, must have remembered that incorrectly, then. i thought it was pulse legnth = gate length for some reason. must have confused it with some other sequencer…

> You have to fake it with envelope decay.

yes, that’s what i did in those demo clips - set the sustain level to 0 and just use ad = pseudo ar…

Thank you.
I’m pretty free this weekend so I shall have go with it and the other apps.

ok, i installed the new version, but now my midipal is behaving really weird.

naturally i first tried the sequencr app in note clock mode (using the same setup described here - minus the 505). at first, it seemed to work fine. but when i switched the midipal off and on again, it wouldn’t play any notes at all (although the display went from “run off” to “run on” when i hit ‘play’ on the tr8). then when i manually triggered a note on the bass station, it did play a sequence, but it wasn’t the sequence i had last recorded into the sequencr app. it sounded more like a garbled version of some earlier sequence.

i have since experimented with different settings - using the internal clock instead of clock note etc, and it’s always the same: as long as i record a new sequence and just play it back, it works. but as soon as i switch the midipal off and on again or load a different app and then come back to the sequencr app, it doesn’t play back the last sequence recorded like it should, but instead first doesn’t play anything, and then after receiving a note in the sequencer midi channel, plays some garbled mix of earlier sequences. :frowning:

@pish: have you given it a try? does yours show the same behavior?

@pichenettes: does this ring a bell at all? would you say it’s a bug of the new fw, or maybe something wrong with my midipal or the setup i’m using (maybe some kind of midi loop thing - haven’t found a way to switch off ‘soft thru’ on either the midipal or the bass station)? anything specific you would like me to try?

Thanks for the report, I’ll make more tests… Might be related to the different memory layout that was required to save the extra clock settings…

in the meantime, i’ve experimented some more: what i said about the midipal having to receive a note in order to start playing a (garbled) sequence after having been switched off and on was wrong. it appears it just takes some time until in starts playing that garbled sequence…

I could not reproduce the problem. Have you done a “” after the upgrade? You have to. Anybody else have observed this?

Are there other people interested in this? It looks like I’m wasting my time here…

I am interested. Have no Time atm though thats why i have Not commented/tested it so far.

hm, that’s strange. i did indeed to a reset.
will do another and experiment using separate synths/keyboards for input and output to eliminiate the possible midi feedback loop (although i don’t really see how that could explain the issue).

[edit:] another factor might be the midi merger. it’s midi powered, and sometimes behaves strangely. i’ll try to elminiate that as well… [/edit]

i’ll have some limited time to try this today, then i’m out of town for a couple of days.
but i’m still very much interested in this feature - it’s fantastic!
(i was a little bemused by the lack of others’ feedback, too - this clock note thing rocks!)

ok, did some more tests - still with the old setup:

for the first 10 or so minutes, only one of the two sub-issues i had reported earlier showed up:

after switching the pal off and on, or after going to a different app, playback of the stored sequence only starts after some delay.
but when it did start, the sequence was ok.

during this first test period, i had only entered notes, no accents or slides. then i started doing sequences with slides and accents, then new sequences without slide or accent etc. and after a while, the second issue also started to occur:

after switching pal off and on, or coming back from a different app, the sequence (initially played back with a delay) wasn’t the one i hat last entered. instead, it was either an earlier sequence or a garbled version of one such sequence (not sure). but that ‘wrong’ sequence always has some slides and accents in it, even if the last sequence entered had neither.

so maybe it’s got to do with accents and slides?

[edit:] sequence length might also play a part. when entereing a short sequence (like, 4 notes), the ‘wrong’ one that plays instead, is always longer (8 notes).

after more testing, eliminating the merger (lots of plugging midi cables in and out involved here) and adding a shruthi as midi destination for the pal (using the bass station as kb only, thus eliminating any possible midi loop):

the delay is shorter without the midi merger.
but the garbled sequence issue is consistently there, garbled sequences always with some accents in them.

so my guess is that it does have to do with accents and/or slides.
either that, or there is a hardware issue with my midipal?

ok now i’m confused.

did another reset. re-entered my note clock settings (clc11, cln d#3) and set the sequencer clock to note again.
entered a 4-note sequence without any slides or accents.
sequence playback clocked by tr8 notes worked just fine.
switched pal off and on again.
started the tr8 as clock note source again.
pal plays 8-note sequence: the original 4 notes with some notes and a rest added from an earlier sequence.

no accents or slides involved this time.
no merger or midi loop, either.
so nothing to do with any of those?
but it’s definitley there. :frowning:

btw i’ve been runnig the pal on a battery all this time.
next test: switch to a wallwart instead (hope i can find one).

[edit:] nope, running the pal on a wallwart now, issue still there.
i’m afraid that’s all i can think of right now. or is there anything else i might try?

I’ll give it a test tomorrow. Been busier than expected.

I had time to try it with the arpeggiator just now, and it works for me. In fact, I had too much fun and forgot the time. :wink: Will continue testing tomorrow.