For assigning instruments and note number interpreters (e.g. mtof) to blocks of notes, and moving such a block of notes around.

If you want eight sequential notes playable, but split up across different parts of the keyboard, you can assign a control block to their intended locations on the keyboard, and set the output blocks so the higher control block picks up where the lower one leaves off.

In-between those two blocks the keyboard may switch to a different tuning, or give abstract key controls, by setting a third control block to start after the fourth note.

First version, so bound to have bugs.

Package:
http://dl.dropbox.com/u/21023661/MIDImap-1_1.7z

Files:
http://dl.dropbox.com/u/21023661/MIDImap.pd
http://dl.dropbox.com/u/21023661/MIDImap-help.pd
http://dl.dropbox.com/u/21023661/rangeindex.pd
http://dl.dropbox.com/u/21023661/rangeindex-help.pd

(resolved)

Bug tracker is broken, so:

Fails to recognize inputs in right to left order, while same as their execution order, when inputs not issued by trigger. Even routing the inputs through "sync" with "mode all" fails. Causes ghostnotes when used with notein, and other awful sideffects.

EDIT: Actually sync does fix the problem a little bit, but require 1 has to be used instead to fix the retained input. There's no clear reason why it works sometimes and not other times, or why the fix changes.
(on last edit, had forgotten a sync earlier)

It only occurs when an input is processed first.

Demo:
Bang one pair of floats into pack and another pair via t b b.

Other info:
Snow Leopard

I have a subpatch that plays a sample at a frequency (using tabread4). I need to play one at each MIDI note without cutting off an actively playing sample. How? Will post innards if necessary.

@Maelstorm said:

So, what's the bug, then?

The bug is, if you don't sync on all inlets of all the patches going in, and all the outlets, it looks like you get the right list of outputs, but on further inspection you get the unsynced outlet double, first with the old list and only its spot in the list changed, then with the new data.

And the error is that the information going to all outlets can't also be the trigger of the later ones if it's to reach the earliest outlet first. In the narrow scope it sends the information earliest to latest, so it appears the outlets should execute in the right order, but in the broad scope the earliest is only executed after that information triggers the later outlets.

Basically, the problem stems from the double semantics of t f f for splitting information and for controlling order of operations. Because it's on the trigger inlet, the program has to be analyzed at multiple scales to detect the problem.

Execution order is probably one of the most consistent things in Pd. There is a standard protocol for outlet order in that if they are all to be output "at the same time", they would actually output from right-to-left. But sometimes outlets are independent and shouldn't be output at the same time, so it is up to the user/developer to get the execution order right if it matters.

Right. This would only be for outlets in the same. I'm working on a clearer model of the problem. Since writing above, it seems like one solution is a dummy splitter, or some narrower-scale splitter, which will only control order of operations as far as satisfying one patch's cold-before-hot requirements.

@Maelstorm said:

And I also don't see what this has to do with [pack] because you're not even using it here.

A bad conclusion from underisolation. Like a memory leak, the bug shows up somewhere completely different from the source.

The problem, as far as I can tell, is that you are trying to execute the rightmost outlet of your abstraction last when it should be the one that is output first.

Ah! I'm not, thank you. Here's it fixed:

http://dl.dropbox.com/u/21023661/MIDImap-1_1.pd

The information just needs to reach the right cold inlet first, the leftmost two still need to execute last.

@Maelstorm said:

I'm not really sure what it is exactly that makes you think that this a control flow that doesn't conform to Pd's usual standards.

If outlet order took precedence, the programs could be equivalent. PD is weak on redundancy, which makes it difficult to build conceptually or quickly. And when you expect that redundancy, it ends up looking like all kinds of other bugs. So I mistook the problem again, thinking if you weaved the execution order a little, even if it still came out in right to left execution, it could desync with itself during that weaving.

Far as I can tell this is a reasonable control flow, and that it isn't interpreted as intended disagrees with the semantics of PD. Has anyone tried fixing this before?

The first edit works, but the second fails. The -1 is on the wrong inlet, but when fixed it's retaining the last instrument. Bad block crossovers, stuck notes (0-velocity sent to correct instrument), and the first response from the abstraction is wrong. But good note crossovers, unlike with the original.

I'm stuck with this browser's troubles because of technical limitations.

@mod said:

you can attach patches directly to this forum. No need to use dropbox. Just make sure you hit "Post reply" not "Quick post"

I don't know what it is you have uploaded in the post you have just linked to, but it doesn't look like a pd patch.

It gives me a blank screen when I try to submit a post with an attachment. I'll upload the contents of the 7zip individually.

There's some misunderstanding. I only actually use the note outlet of notein, the desyncing occurs when I return to pack it with the velocity. I've uploaded the problematic abstraction. You can see there's a complicated execution order which leaves the last outlet unsynced from the first two.

See: http://puredata.hurleur.com/viewtopic.php?pid=29914

DATED - discussion concerns:
http://dl.dropbox.com/u/21023661/MIDImap-1_0.pd

By the way, thank you both for looking into it.