(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

you don't need the [pd ggg] part by the way; for all intents and purposes, it's totally useless.

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

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.

@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.

ok i had a look at at,
You are well on the right track, and all you need is a slight adjustment.

see in your MIDImap abstraction, how you have a [t f f] object after the inlet, that's great. It's exactly what you should do.

I think i can see why you are resorting to the [sync] object, because sometimes execution order cannot be forced with just a single trigger object. In your case, you want the [rangeindex] abstraction to output its value to the right inlet of [pd fmtNote], but then you also want the same output to trigger your leftmost [outlet] last, so as to get your next [pack] sorted the right way.

What you'd normally do in a situation like this is use a couple of cascaded trigger objects, and also queue some values sending them to the right inlet of a storage object such as [f ]

i have attached an edit of your patch to demonstrate. Note that i didn't actually test this, but to my eyes it looks like it should work. At least you should see the logic behind it too.

http://www.pdpatchrepo.info/hurleur/MIDImap-edit.pd

here's an even neater way of doing it. All i have done here is exploit the fact that A - B is the same as A + B * -1

this allows me to switch the inlet order of your [pd fmtNOTE] subpatch, and make the rest of the execution order quite straight forward. No messing round with the [sync] object or anything like that. Just following logical right to left execution order and using triggers properly.

http://www.pdpatchrepo.info/hurleur/MIDImap-edit2.pd

by the way, if you can try another browser, you might have better luck with attaching files to this forum. I think there were 1 or 2 browsers that weren't playing along too well.

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.

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?

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. And I also don't see what this has to do with [pack] because you're not even using it here. I guess you're using [sync] to get around it, but it would be MUCH easier to understand why you're using [sync] instead if you show the version using [pack] that isn't working.

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.

Having said that, I tend to use [pack] to deal with execution-order situations where re-patching might be cumbersome. Then you [trigger] things in whatever order is convenient, [pack] them (making sure the hot inlet of [pack] is the one getting the last [trigger]), using dollar variables in message boxes to rearrange them, and finally [unpack] them so they are sent in the right order. Like this:

This one is triggered last
|
v
[pd fmtNote] [tabread instr] [tabread prog]
| / /
| / /
| / /
| / /
[pack f f f ]
|
[$2 $3 $1( <-- this will reorder the list so that the note is at the end
|
[unpack f f f]

Take a look at the attached for a clearer look.

http://www.pdpatchrepo.info/hurleur/MIDImap_edit3.pd

@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.

@LokiClock said:

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

So, what's the bug, then?

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.

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.

@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.

@LokiClock said:

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...

They key word here is "you". This is a user error, not a Pd bug. It's up to you to make sure things are executed in the order you intend.

Basically, the problem stems from the double semantics of t f f for splitting information and for controlling order of operations.

[t ] doesn't split anything. It just outputs the incoming message multiple times in right-to-left order (as well as possibly changing the message, such as in [t b f], but that doesn't seem relevant here). In other words, it's just meant for controlling order of operation.

Right. This would only be for outlets in the same. I'm working on a clearer model of the problem.

Clearer? Maybe I'm just too entrenched in the way Pd works, but you're actually just confusing the hell out of me. To be completely honest, I'm getting the impression that you're expecting Pd to do something it doesn't claim to do.

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.

That sounds like what [t ] is meant to do.