'Hinder' pipe? – delaying message types without repeats

Midihub Feature Requests
1

Hey @Giedrius, as much a query as a request:

I have a hunch that virtual mappings might give rise to more of a need to “hold up” certain messages
(so that any Transforms that might act on them get their virtual mapping updates in time before the message gets to the pipe in question.)

In a recent patch where I definitely needed this, I had already converted to a Note so could fudge a Delay to do the job, but that often won’t be the case.


This pipe would therefore be

  • like Delay but without any Repeats (or many other Delay properties like Dry/Wet etc)

  • but covering a wide range of message types – including Note On & Off.

  • If there’s byte-space, like Transform, it would benefit from “1st byte/Id in Range” and Channel too.


If you agree it might be useful, I suppose it would need the same 32 message memory limitation as Delay
(it’s a moot point what happens if #messages exceeds limit)


My guess is that, in full generalised Midihub style, it would end up being put to quite creative uses.
(hey, mapped to a Saw Up synced LFO –& a few “ranged” Transforms–we get the possibility of shuffle timing!)



PS. Hinder is a pretty rubbish name but hopefully folk know what I mean.
If not, they can always think “Retard”…

2

Do you want this in milliseconds resolution? Or synced to BPM? Or manual triggers through mappings? :slight_smile:

1 Like
3

For mapping-delay purposes, I’ve been using 1-2ms (assuming that’s plenty for a mapping event created from the same message to modify a Transform Arg before the ‘delayed-temporary-note’ gets to it)…

…but if a pipe was designed to cater for that, I guess I just assumed it would also have a Sync option.

(would that sort of 1/96 quantise qualifying messages as a by-product?)

I hadn’t thought of “store until trigger”; that’s got some serious scope!

4

Delayed transforms synced to BPM with the same range as the Delay pipe… :exploding_head:

1 Like
5

Yep, that was my assumption about what Giedrius & Pranciskus would do, if they ran with the idea.

Now G asks about it, I wonder whether it’s also viable to have a ‘Next Clock’ option and/or whether it’d be useful. I’d want to keep that separate from the option range so the latter could have the same mapping range as other existing Synced pipes.

The Trigger notion has got me going though, especially combined with a virtual mapping that’s reponding to another message like a Pressure threshold…
…:exploding_head: indeed!