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.

Okay, I found only outlets of the subpatch need to be synched. Only one outlet was doing this. Still don't understand why it happens, though.

@mod said:

basically, if you follow this golden rule, you won't go wrong:

NEVER take two patch cables from a single outlet.

It's illustrative. In my actual patch there's no such mistake. Still, the problem doesn't appear until the patch/unpatch phase.

And apologies, I forgot to simplify the ggg subpatch on the MIDI side: You can simply send inlet to outlet to see the bug. It's now updated.

I see it's an issue of the creation order of the lines from notein.

Redoing them fixed it in the example, but not in my patch. Still looking.

@Maelstorm said:

Your attachment didn't work, please try again. [pack] is working just fine with me on Leopard.

Try now. It's about its interaction with subpatches.

Here is the bug isolated:

http://dl.dropbox.com/u/21023661/ProcessedPackBug.pd

Or if that won't download:

http://dl.dropbox.com/u/21023661/ProcessedPackBug.txt

(EDIT Missing connector in example)

Actually, this business is probably built-in. See help files for all mentions of "exponent" here.

Try entering "b^t for b=50" into wolframalpha.com and going from there. Here's an overview:

Corners; After operation
(0,1), (1,b); b^t
(0,0), (1,b-1); -1
(0,0), (1,1); /(b-1)
(0,0), (1,volend-volstart); *volend-volstart
(0,volstart), (1,volend); +volstart

Function in development.
At this point you can replace b and t with $f1 and $f2 to get a valid [expr].
b^t
b^t-1
(b^t-1)/(b-1)
From here on you also need $f3 and $f4 for volstart and volend.
(b^t-1)*(volend-volstart)/(b-1)
(b^t-1)*(volend-volstart)/(b-1)+volstart

Exponential fades are not circles, but they do look a bit like ellipse quadrants. If that's not what you mean, you'll have to find a picture (or look here). If it is, here you go: Exponential curves on linear impulses (not dB) sound smooth and straight, because the ear translates takes a logarithm of them (as it does with frequencies) to become linear. This is called an exponential fade. By changing the base you can affect the sharpness of the fade.

Generally you want to avoid finding matches on a curve for your time & amplitude, so you'll stretch the exponential's known points to your start and end points and amplitude. Exponentials of all bases b go through the points (0,1) and (1,b), and we want them to go through (start, volstart) and (end, volend).

Crop the output by subtracting 1 from the whole function, so that b^time becomes b^time-1 (not b^(time-1) ), and those points become (0,0) and (1,b-1). Stretch the amplitude by dividing by b-1 and multiplying by volend-volstart, sending (1,b-1) to (1,1) then (1,volend-volstart). The function is now: (b^time-1)*(volend-volstart)/(b-1). Raise this clip to meet your desired amplitudes by adding volstart, so that the points are now (0,volend), (1,volend), and the function is (b^time-1)*(volend-volstart)/(b-1)+volstart.

All that's left now is stretching and clipping the input, which can be done a number of ways, but all entail turning start-end into 0-1. You can give this expression a time input from a [line] that ramps from 0 to 1, from start until end in ms. You could, of course, run that line through another function first, which still outputs from 0 to 1, and make a more complex envelope. You can bake the stretching and clipping into the expression by turning time into (time-start)/(end-start), so that as time runs from start to end, the function outputs as if running from 0 to 1.

You're a lifesaver. <3, <4, & <5.

How do you connect a notein to multiple voice polys? I need to use separate instruments for some notes. I tried:

[notein ]
| | |
[>=60] | |
| | |
[bondo 3 ]
| | |
[pack f f f]
|
[route 0 1 ] //>=60
| \
[poly 4 1] [poly 4 1]
...

Which doesn't activate any voice on the left with note >=60 (or right <60), but it triggers extra notes and notes stay on after the keys aren't pressed.

Thanks a bunch! You still have to manually create a copy of the patch for each MIDI note, huh? I wish it could just be an array index.

EDIT: Ah, what I didn't mention is that I want a sample to restart if it's playing at the same note that just got hit on the keyboard. This method should do that if I make a different voice for every key, right?