What's wrong with this [text]?
This code works just fine in a max patch. It transfers the contents of the [coll] to the [textedit]. But as soon as i copy it to my m4l patch, it doesn't (I'm not even worrying at this point about connecting it to anything else. All i do is paste then turn on the [metro] and it's broken). The [print] reports that the messages leave the [coll] in the right order, but they appear in the [text] in the wrong order, and sometimes the entire message doesn't even make it out of the [text]. Aggravatingly, if you click the button by itself, it does work, but the [metro] feeding into that same button does not. Any ideas?
By the way, when you open that code, what's in the [textedit] to start off with are the mangled results of using it in a m4l patch.
Not sure I quite understand what you want to do.. but those back to back dump commands look suspect… As my Uncle Henry always said, "Dumps take time."
Try executing the second dump via the bang from the fourth outlet of the coll… so you know for sure that the coll is done dumping before the trigger sends a dump command to the text object.
A carriage return after each dumped coll item may also be the ticket..
Haha thanks for the suggestion, but it's no go. Even if i take out that second dump entirely, the contents of the [text] still wind up being wrong. If you copy that code into a .amxd of yours, can you replicate my results, or does it work for you?
What i'm trying to do with this section of code is transfer the drum assignments of a sampler i'm working on from the coll to the textedit which has a [pattr @parameter-enable 1] bound to it, in order that they'll save with the set. This section of my patch looks like this in its entirety:
The closebang wasn't working (I think because by the time the closebang goes off the device has already "closed" and the pattr no longer checks for changes in its bound object??) so i was trying to institute a metro which would periodically keep things saved. Of course I'm open to suggestions, if there's a better way to accomplish this.
As for the carriage return, I had already tried that. The problem is then the [text] dump causes multiple messages to come out, which overwrite each other when reaching the [textedit]. I could use append, but then there's no space between the separate entries. Is there a way to "append" things to the contents of a textedit, keeping spaces in between? That would solve the problem. Maybe [combine]ing with a " " or something?
I don't get it. Did you try the patch I posted? There is no overwriting. You can dump a thousand file names to multiple chained text objects without losing any of them.
Yeah i tried it. I meant the overwriting happens in the [textedit] not the [text].... Although, can a [text] be bound with a [pattr]? That would simplify things...
OK, i now realize that i was mistaken about there being no space between things that are appended to a [textedit], so the carriage return method would work, however it doesn't fix the problem i'm experiencing. Here's what my code currently looks like:
The contents of the coll are:
75, 12 CYCdh_Kurz07-Perc03.wav;
101, 21 CYCdh_Kurz07-Tom01.wav;
80, 3 CYCdh_Kurz07-Crash02.wav;
and yet, with the metro on, this is what ends up in the [text]:
12 CYCdh_Kurz07-Perc03.wav 21 CYCdh_Kurz07-Tom01.wav 3 CYCdh_Kurz07-Crash02.wav 75
101
80
which is baffling on multiple levels. Again, only in m4l, not in an ordinary Max patch. Thanks for helping me troubleshoot; it's helpful to throw ideas back and forth.
OK, I think I understand. How about this…
OK… I got it...
Check the defer attribute in the metro inspector (or send the message [defer 1] to the metro).
Good luck with your project!
Ahh thanks! I had a major meltdown with Max so I haven't had a chance to try it out yet, but i suppose it makes sense enough. Seems to be how it often goes.. When in doubt, defer it.
Yes. It does seem to do it.
Good to hear. And thanks.. this motives me to spend more time with M4L.