I'm working with [midifile] to create algorithmic scores from analog-style synthesis models. Really I'm at the beginning stages of doing so.
My flow is to generate data, write it into a MIDI file, and then open it in Finale to see the results. Unfortunately, I'm seeing an accumulation of previous notes that appears at the start of each measure.
Here's a picture of the patch and the output: https://i.imgur.com/t4naCah.png
Any idea what I'm doing wrong? I'm assuming there might be some kind of problem with how I'm creating noteoff commands.
What I remember from study is that the MIDI spec has both noteon and noteoff messages, but most instruments just use noteon messages with zero velocity. Do sequencers translate those zero velocity messages into noteoff messages before saving them into a file?
Thanks, Sam
As with most unpredictable problems in pd, this one was solved with a trigger object banging a float so the velocity could be set before the note.
I've had this problem for days and solved it just after posting to the list.
On Wed, Feb 9, 2022 at 12:52 PM Samuel Burt composer.samuel.burt@gmail.com wrote:
I'm working with [midifile] to create algorithmic scores from analog-style synthesis models. Really I'm at the beginning stages of doing so.
My flow is to generate data, write it into a MIDI file, and then open it in Finale to see the results. Unfortunately, I'm seeing an accumulation of previous notes that appears at the start of each measure.
Here's a picture of the patch and the output: https://i.imgur.com/t4naCah.png
Any idea what I'm doing wrong? I'm assuming there might be some kind of problem with how I'm creating noteoff commands.
What I remember from study is that the MIDI spec has both noteon and noteoff messages, but most instruments just use noteon messages with zero velocity. Do sequencers translate those zero velocity messages into noteoff messages before saving them into a file?
Thanks, Sam
Am 9. Februar 2022 19:07:45 MEZ schrieb Samuel Burt composer.samuel.burt@gmail.com:
As with most unpredictable problems in pd, this one was solved with a trigger
well, *that* was predictable...
mfg.sfg.jfd IOhannes
Most of the puredata tagged questions on stackoverflow are message order bugs caused by fanning outlet connections. Should Pd warn the user when one outlet is connected to multiple objects?
On 09.02.22 21:08, IOhannes m zmölnig wrote:
Am 9. Februar 2022 19:07:45 MEZ schrieb Samuel Burt composer.samuel.burt@gmail.com:
As with most unpredictable problems in pd, this one was solved with a trigger
well, *that* was predictable...
mfg.sfg.jfd IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
It's a bit more tricky. Fanning control outlets are not a problem per se, only if those connections go to one or more *hot* control inlets. Fanning out to cold control inlets is perfectly fine; some people still like to use [trigger], but technically it doesn't make a difference. Also, fanning out to signal inlets isn't problematic, either.
So maybe Pd could warn if fanning outlets go to one or more hot control inlets.
On 10.02.2022 10:09, Max wrote:
Most of the puredata tagged questions on stackoverflow are message order bugs caused by fanning outlet connections. Should Pd warn the user when one outlet is connected to multiple objects?
On 09.02.22 21:08, IOhannes m zmölnig wrote:
Am 9. Februar 2022 19:07:45 MEZ schrieb Samuel Burt composer.samuel.burt@gmail.com:
As with most unpredictable problems in pd, this one was solved with a trigger
well, *that* was predictable...
mfg.sfg.jfd IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Thu, 2022-02-10 at 10:09 +0100, Max wrote:
Should Pd warn the user when one outlet is connected to multiple objects?
I'd rather want Pd not to do that.
There are too many cases where fanning outlet connections are OK.
I believe it's more valuable if people do not fanning connections
because they understand their implications rather than because a message tells them to avoid them.
- I'm personally not so fond of the idea of giving people patching
advice.
Roman
On 2/10/22 10:30, Roman Haefeli wrote:
- I believe it's more valuable if people do not fanning connections
because they understand their implications rather than because a message tells them to avoid them.
but maybe they can be made aware of the implications if they were made explicit.
- I'm personally not so fond of the idea of giving people patching
advice.
i understand that.
on a related note: since Pd-0.52 it is no longer possible to connect a single outlet to single inlet twice. after reading this thread , i wonder whether this was premature and whether we should undo that change.
gfmasdr IOhannes
On Thu, 2022-02-10 at 15:00 +0100, IOhannes m zmoelnig wrote:
on a related note: since Pd-0.52 it is no longer possible to connect a single outlet to single inlet twice. after reading this thread , i wonder whether this was premature and whether we should undo that change.
Can you elaborate?
Not sure if I rephrase that correctly, but I thought Pd is following a paradigm of "the patch is what you see". By solely looking at the patch, you understand its initial state and its mechanics. Having double connections clearly breaks that. I'd assume double connections happen always by mistake and they cannot be distinguished from single connections. I think it's a good thing that they are suppressed now.
Roman
On Thu, 2022-02-10 at 10:30 +0100, Roman Haefeli wrote:
- I'm personally not so fond of the idea of giving people patching
advice.
Let me rewrite that to 'unsolicited patching advice'.
I was the other day stumbling across a not-so-trivial-to-resolve bug. The problem turned out to be a [loadbang] from an abstraction initializing stuff in the parent patch that again initialized stuff in other abstractions. Because there is undefined order among the abstractions' [loadbang]s, the other abstraction received a message before it was ready to do so.
Although very similar to the fanning outlet connections anti pattern, this (loadbang-with-outside-effect-in-abstraction) might be a less known one.
I'm curious what other anti patterns people learned to avoid during their patching career.
Roman
-
Christof Ressi -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Max -
Roman Haefeli -
Samuel Burt