@polyplexmescalia said:

It will be difficult but I will try nontheless before I just use the VST. Thank you!

Had a thought, you might not even have to simulate true mp3 encoding -- you might just randomly zero out some bins probabilistically, and weight the zeroing-out so that higher or quieter bins are more likely to be discarded. That would mess up transients and give that watery effect to noisy sounds like cymbals (as usually happens with low-rate mp3 encoding). Worth a try, and much easier to implement than a full psychoacoustic model.

hjh

@willblackhurst said:

well I forgot to say , things like youtube dont work, with dsp on. Ill take a look at your suggestions. Thanks.

Right, and oid is assuming that you're using PipeWire, which based on this comment, I think you're probably not.

Without PipeWire, you need to configure PulseAudio to be a JACK client. Plenty of websites on that. I ran my Ubuntu Studio system like that for years. And it's fine, but...

PipeWire makes this type of problem go away. It's so much more flexible. Like, in online meeting software, I'd have to pipe JACK apps' audio into the PulseAudio mic input, where the meeting app would just destroy it. Now I can "share computer audio" and it works transparently.

hjh

@polyplexmescalia Probably the easiest way is to use vstplugin~ to run Maim directly.

MP3 encoding is based on analyzing FFT frames and throwing away bins based on psychoacoustic rules. I think this will be difficult to implement in vanilla Pd.

hjh

@willblackhurst said:

dont put length probably. note-on doesnt use length. makenote uses length.

Nobody has mentioned length in this thread... cause of the problem was already found anyway.

hjh

@midi said:

I need to output “note on velocity 0”
to the software

the software refuse to recognize
any note off messages

I just tested as follows (sending a nonzero midinote number of course):

... and found that (at least in Linux, using the ALSA MIDI protocol) [midiout] transmits the bytes exactly as given, without transforming note-on to note-off.

I don't know about Mac or Windows MIDI behavior.

But... when I set up a MIDI responder in SuperCollider (because SC distinguishes between noteOn and noteOff, unlike Pd where velocity is the only thing that distinguishes them), I found that SC changes in note-on message with velocity = 0 to a note-off message.

When I set, in SC, MIDIIn.noteOnZeroAsNoteOff = false;, then the zero-velocity message was received as note-on.

Now, that's not a guarantee that it will do this on all platforms. But, I don't find anything in Pd's sources that changes the status byte in this case. So if that's definitely always happening in your environment, then it must be either PortMIDI in Pd, or the receiving software is doing it.

hjh

@impression said:

• for what are you using text search parsing->moses->1000 for? I just noticed it turns voice number 1 into a zero, but don`t really get how and why.

[poly] assigns an index to note numbers. You'd think this would be easy to use directly as a row number in the [text], but [text] treats high row indices as "append" rather than "put at this exact row," so you don't have a guarantee that poly index 3 maps onto text row 2 (poly counts from 1, not 0).

So to find the row index to use, there are two cases:

• Search for the poly index and find it -- the [text search] result is >= 0. In that case we just want to pass the row index through -- that's the right branch of moses.
• Or, [text search] didn't find it. Then its result is -1. That's not a valid row index for [text put], so, we have to replace it with a high number, to tell [text put] to append. So moses --> "1000" means simply, replace negative numbers with 1000 but pass 0 or positive numbers through.

• also I don't fully understand "pd notecount", even you explained already what it does, it lets my brain explode
  You count up + 1 once a note is pressed and count down -1 once its released. I don`t know what's the idea of "max 0" feeding itself back into + though.

A negative note count is invalid, but could happen if, for instance, you started the patch running while holding keys on the MIDI keyboard. The max 0 just prevents the count from being negative.

It all works as you showed, but when I set list split to 3 it basically freezes PD. Do you know by any chance why?
I would need to split my list into 3 later on.

It's very important, when using [until] for looping, to use either a fixed count of loop iterations or to make sure that the stop "bang" signal goes into the right inlet. If it's freezing, probably that's not happening.

hjh

@whale-av said:

But fortunately, [raindrops] is included in the tarball of all files here....... http://aspress.co.uk/sd/ so it is an omission mistake on the page you linked to....

Ah ok ... thanks.

Yeah, it's an interesting book but sometimes hard to see what is what. This [raindrops] abstraction is a parameterized version of another figure in the book, but without a clear explanation in the text AFAICS.

Thanks for the tip --

hjh

Sorry for what is perhaps a rather specific question, but... does anyone else have the Andy Farnell Designing Sound book?

I never did that much with it because there's a fundamental editing mistake (IMO) -- many patches refer to abstractions, but there is usually no explicit link between the name of the abstraction and the figure in which the abstraction is defined.

Case in point (and relevant to a project) -- figure 38.7 (page 445) uses an abstraction [raindrops 20 0.1].

http://aspress.co.uk/sd/practical15.html doesn't have it.

Actually I'm looking through that chapter for any abstraction that has only $1 and $2 but not $3 or higher (bc the use of the abstraction provides only 2 arguments) and I don't see one -- so maybe it was just omitted?

Just wondering if anyone had run into this and found a solution.

hjh

@impression said:

Omg, never in my life would I have figured that out

Around 2019 or 2020, I might have said the same thing.

I'm more accustomed to working with the high-level language, SuperCollider. In this case, it's easier to write this logic in SC because, using SC arrays where pack/unpack is used in the Pd patch, you can access any element at any time, and pack a new array just by writing [item, otherItem, thirdItem, etc.]. In SC, most of the spaghetti in the orange part could be written with a single line: [list[2], SystemClock.seconds, list[1], list[0]].

The orange bit is really only reordering the input list, and adding an item for the current time. (Why did it have to be ordered with velocity first? Because that's the only way to get [route] to split note-on and note-off.) It looks massively complex, but it's really not doing anything more than that. The complexity arises because data flow out of [unpack] in a different order than they need to go into [pack] -- the [unpack]'s right outlet needs to be withheld, so that [pack]'s hot inlet at left is not triggered until all the other inlets have been populated.

There are plenty of tricks for that (e.g., the use of [f] on the orange side). It took me a few years to learn them. You can learn them too.

hjh

@impression I think it's not possible to avoid the central problem, which is associating a note-off message with the prior matching note-on message. Unfortunately, this problem takes some careful thinking. It's tempting to avoid doing this careful thinking at the incoming-message stage and try to push the problem off to another part of the patch. But, I think everything is going to be easier if the note parsing is done correctly in the first place.

I think you will need one [text] just to parse the messages into chords, and then another [text] as a chord repository.

The basic flow I'm thinking of is:

• Use [poly] to assign an index to incoming note numbers. (Why? Because, when a note-off message comes in, you have to find the matching note-on record and look up the time. Then you can use that time to calculate the duration. There is no way to do this without matching note-on and note-off, and [poly] does this for you.)

• Note on: Some jiggery-pokery to rearrange the note-on data into the format "poly-index timer-value note-num velocity" and then write this list into a [text] at the row number where that index lives.

• Note off: Find the [text] entry matching index, unpack it, subtract the current time from the message's time (to get duration), pack into the desired format "note-num vel duration' and add to the current chord.

I had to make a decision about how to know when the current chord is finished. In this patch, it's when all notes have been released -- [pd notecount] gives a bang when a note-off decrements the active note count down to 0. That may or may not be right for your use case, but that part can probably be adjusted without requiring too much surgery on the rest.

In any case, in the end I get messages such as the following:

chord: 69 101 394.739 62 101 394.739 60 101 394.739 64 101 394.739 67 101 394.739 71 101 394.739
chord: 65 101 394.739 72 101 417.959 67 101 394.739 69 101 394.739
chord: 71 101 394.739 65 101 394.739 60 101 394.739 62 101 394.739 64 101 394.739 72 101 394.739
chord: 65 101 394.739 64 101 394.739 67 101 417.959 72 101 394.738 71 101 394.739

... which could be read out in groups of three for playback. (The durations and velocities are all the same because I was testing with MIDI notes from SuperCollider -- I had specified a duration of 400 ms for each note and Pd is pretty close to that. So I think that confirms the approach.)

(Note that it's a good idea to reset the [timer] at the beginning of a run -- I set up MIDI controller 37 as a trigger for that but you could do it any other way you want.)

hjh

midi-parsing.pd