@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

@impression What if you store your chords in the format:

note0 vel0 dur0 note1 vel1 dur1 ...

That is, don't bother with clumping all the note numbers together at all -- interleave them from the start.

Then your iterator can "get $1 3" and increment by 3 each time.

Maybe an example later when I have a bit more time.

hjh

@impression said:

I can’t really use [clone] for my synth setup.

I'm curious, why is that? There's probably a solution. If it's the first time you're using [clone], I can see how it might be tricky to figure out, but "haven't figured it out" may not be the same as "can't use it."

I’d basically need to generate my own note on and note off messages manually.

That's probably the [makenote] object.

hjh

For computer-to-computer communication, Open Sound Control over a LAN may be easier than MIDI (as a transport device).

hjh

BTW though: I hadn't looked closely at the sources earlier, so I was conjecturing. Looked just now. If we take, say, "unpack" as an example of an object that typically has multiple outlets, and see how it responds to a list:

in m.connective.c:

static void unpack_list(t_unpack *x, t_symbol *s, int argc, t_atom *argv)
{
    t_atom *ap;
    t_unpackout *u;
    int i;
    if (argc > x->x_n) argc = (int)x->x_n;
    for (i = argc, u = x->x_vec + i, ap = argv + i; u--, ap--, i--;)
    {
        t_atomtype type = u->u_type;
        if (type != ap->a_type)
            pd_error(x, "unpack: type mismatch");
        else if (type == A_FLOAT)
            outlet_float(u->u_outlet, ap->a_w.w_float);
        else if (type == A_SYMBOL)
            outlet_symbol(u->u_outlet, ap->a_w.w_symbol);
        else outlet_pointer(u->u_outlet, ap->a_w.w_gpointer);
    }
}

... where each output value calls either outlet_float() or outlet_symbol() or outlet_pointer(). It'll move to the next outlet when the outlet_ function returns.

m_obj.c:

void outlet_float(t_outlet *x, t_float f)
{
    t_outconnect *oc;
    if(!stackcount_add())
        outlet_stackerror(x);
    else
        for (oc = x->o_connections; oc; oc = oc->oc_next)
            pd_float(oc->oc_to, f);
    stackcount_release();
}

OK, check for stack overflow and then call pd_float() for each connection from that outlet. (_bang, _symbol, _pointer are similar.)

m_pd.c:

void pd_float(t_pd *x, t_float f)
{
    if (x == &pd_objectmaker)
        ((t_floatmethodr)(*(*x)->c_floatmethod))(x, f);
    else
        (*(*x)->c_floatmethod)(x, f);
}

Get a reference to the next object's floatmethod function, e.g. and call it: a method handler --> an iterator over connections --> a connection handler --> another object's method handler, at which point the cycle recurs.

So the way that it backtracks seems to be simply that e.g. outlet_float() returns and the method handler resumes where it left off: normal tree-traversal recursion using C's call stack (without data return, as these are all void).

Gotos do appear in the Pd source but it looks like the vast majority of these are used for early-exit or for input validation before performing some operation -- goto error, goto fail, goto doit, etc. I don't see them in the message-passing functions. (What I also don't see in the message-passing functions is an explicit stack of objects/connections -- stackcount_add() is just a global counter, no real push/pop -- so if I guessed that pd keeps its own stack of objects visited, that was a wrong conjecture.)

hjh

@impression said:

Lets say I want 32 polyphony, that would be an insane effort.

IMO this all comes down to data structure design. A bad design will require insane effort. A good design will scale up to any amount of polyphony you need.

What's the input? From your MIDI keyboard?

What do you need to do with the notes afterward? Just spit the MIDI events back out, or quantize them, etc etc?

[text sequence] is a nice way to store note sequences. Each entry starts with the time delta before this note, followed by the note data, which may be anything you want (e.g., note number, sustain time, velocity, suitable for [makenote] when playing back).

It would really help if you could explain the goal, to help design a way to un-insane the insane effort.

hjh

@oid Agreed, yes, let's move on.

hjh

@oid Thanks. I think this confirms that you and I are talking at orthogonal purposes. What I've been trying to say is that one can use a linked list to implement a stack and use that stack to organize gotos into procedure-call behavior, or one could use a dedicated Stack data type and implement the same behavior using only structured control flow, and the behavior in both cases is that of a procedure call. Pointing out that the one is just a linked list and gotos doesn't make it not procedure-call behavior.

I.e. we're focusing on different levels of abstraction. Or, in answer to your earlier question, "are they really procedure calls or is that just conceptual?" -- I'm mainly interested in the conceptual aspect, yes, and you're mainly interested in the concrete implementation. So any confusion/frustration stems from talking past each other.

hjh

@jameslo said:

Hmm, that's interesting, have you considered Java's use of gotos?

Nice one well, there's a time and place for everything. There are gotos in SuperCollider's C++ codebase, iirc mainly in the long switch blocks in the bytecode interpreter. I guess... it's like second inversion triads. In conventional harmony, there are a few legit ways to use them, but otherwise, don't; same for gotos.

hjh

@oid Perhaps I owe an apology for an excessively critical post -- I can see that I was a bit too heated.

Perhaps part of the problem in this thread is trying to find terminology without agreeing on terminology -- I'm using some terms in a way that you disagree with, or might be misunderstanding to some extent, and vice versa.

I think some of the things that have been said in this thread are misleading in some ways. Message-passing along patch cables isn't a goto -- it just isn't. Gotos have been discouraged for a long time because they're messy. Overuse produces spaghetti code, and goto-heavy code is hard to debug because gotos are history-less -- there's no backtrace to see how you got into a bad place. Pd message passing keeps all the history until you reach the end of the chain. Stack traces are a characteristic of procedure/function calls -- not a characteristic of gotos.

I do see that Pd doesn't use a stack for returning data to a caller. But there have been some statements that seem to go beyond that, for instance, "without a return stack we can't actually return" -- that's true, we can't return data but execution can and does return back to an object that was previously touched.

Again, probably a lot of this is about terminology -- for example, when I used the term "procedure call," that isn't the normal way that Pd users talk about message passing, so there's a bit of "well that doesn't make sense"... but I think the behavior of Pd control objects lines up very closely with the behavior of procedure calls, and I think some of the resistance to this idea has been overstated to some extent or another. (Likewise, to suggest that you totally rejected the idea of a stack is a considerable overstatement -- which I certainly have to retract.)

So I am sorry about getting a bit punchy there -- at the same time, I'm a bit bewildered why so many things I've tried to say in this thread seem to have gotten a "well, no, that's not it" where I guess I hoped for a "hmm, that's interesting, have you considered?"

hjh

@impression The first step is to work out the data structure. If it's my project, I'd go with one of these approaches:

• Save MIDI note on and note off directly, without much analysis. Playback logic would then be very similar to MIDI polyphonic playback.
• Or, use note-off to calculate the sustain duration of the preceding note that matches the note-off pitch. It's harder to calculate that, but then you get a list of notes with parameters "note number, velocity, sustain duration" -- may be more useful for algorithmically manipulating the notes.

What are your thoughts about how to play back the sequence?

hjh