(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

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)

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

@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's my explanation of hot and cold inlets and why you need to use trigger.

http://puredata.hurleur.com/sujet-6381-hot-cold-inlets-execution-order-trigger

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

NEVER take two patch cables from a single outlet.

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

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.

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

@LokiClock said:

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

This is what mod is talking about. If you use [t ] (aka [trigger]) you don't have to worry about the creation order of the patch cords. [t ] will force the correct order you intend.

For example, right now you have this:

[notein]
|\
| \
| \
[pd ggg]

You can't tell just by looking at that which one will be sent first. It will depend on which cord was patched first. However, if you do this:

[notein]
|
[t f f]
| \
[pd ggg]

you can rest assured that the right inlet will get the float before the left one.

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.