^{We will use A-28 Hertz as a reference (base or aggregate).}

^{Add 28 dividers … 1 - 2 - 4 - 7 - 14 - 28 to the base and we obtain the following list}

^{28 - 29 - 30 - 32 - 35 - 42 - 56.}

^{Apply this list to the sonic band in Hertz and we have a basic scale (7 notes/ first octave)}

^{28Hz                     29Hz                     30Hz                     32Hz                     35Hz                     42Hz                     56Hz}     

^{List the harmonics for each of the notes in the basic scale and you have the making of a new musical / instrumental tuning.}

^{This new tuning can be applied / transferred to an existing notation program’s extension providing the program will accept the new tuning and run its oscillators on it.}

^{I want to replace the Equal Temperament Tuning. with the following frequencies, for each note respectively.}

^{NOTE                            Frequency}

                                        ^{in Hertz}

A - 1        28 -

A#          29

B             30

C            32

C#          35

D            42

D#          56 -

E             58

F             60   

F#           64

G            70

G#          84

A - 2        87

A#          90

B             96

C            105

C#          112 -

D            116

D#          120

E             126

F             128

F#           140

G            145

G#          150

A - 3        160

A#          168

B             174

C            175

C#           180

D            192

D#          196

E             203

F             210

F#           224 -

G            232

G#           240

A - 4        245

A#          252

B             256

C            261

C#           270

D            280

D#          288                               

E             290

F             294

F#           300

G            308

G#          315

A - 5        319

A#          320

B             330

C            336

C#          348

D            350

D#          352

E             360

F             364

F#           377

G            378

G#          384

A - 6        385

A#          390

B             392

C            406

C#          416

D            420

D#          435

E             448 -

F             450

F#           455

G            462

G#          464

A - 7        476

A#          480

B             490

C            493

C#          504

D            510

D#          512

E             522

F             525

F#           532

G            540

G#          544

A - 8        546

A#          551

B             560

C            570

C#          576

D            580

D#          588

E             595                               

F             600

F#           608

G            609

G#          616

A - 9        630        

A#          638

B             640

C            644

C#          660

D            665

D#          667

E             672

F             690

F#           696

G            700

G#           704

A - 10      714

A#          720

B             725

C            728

C#          735

D            736

D#          750

E             754

F             756

F#           768

G            770

G#          780

A - 11      783

A#          784

B             798

C            800

C#          805

D            810

D#           812

E             832

F             840

F#           841

G            864

G#          868

A - 12      870

I asked the same thing to Chat Gpt

Thet say ok, it's new we do it

I followes the intructions, installed Python... and now I am stuck

I need me a computer person to help me and the Chat Gpt robo thingy complete the prototype.

// Create an input port, but ump
const port_id = asound.snd_seq_create_simple_port(
    seq.?,
    "Zig Midi In Ump",
    asound.SND_SEQ_PORT_CAP_WRITE | asound.SND_SEQ_PORT_CAP_SUBS_WRITE,
    asound.SND_SEQ_PORT_TYPE_MIDI_GENERIC | asound.SND_SEQ_PORT_TYPE_APPLICATION | asound.SND_SEQ_PORT_TYPE_MIDI_UMP,
);

After that, I have created an async callback to receive the ump packet. is_active is a global variable so that the loop can be stopped outside the async function, while the type UmpEvent is snd_seq_ump_event_t: 

fn processUmpEvent(seq: ?*Seq) void {
    var ev: ?*UmpEvent = null;
    while (is_active) {
        if (asound.snd_seq_ump_event_input(seq.?, &ev) >= 0) {
            std.debug.print("Event type: {d}\n", .{ev.?.type});
        }
    }
}

While the program is run, since I also want to see how midi host that can't support ump behaves to my virtual input device, I decided to open a daw and trying to send something with it; unsurprisingly, although my daw recognized my virtual port, the port don't response to the event since my host didn't send ump event, but this creates some questions since I am not sure how should I handle this situation if I want to build a midi library or a midi host for example, so here are the questions:

- Is the behavior of legacy midi host recognized my virtual input device intended?
- When I build a virtual input device, do I need to check if the new incoming or target device support ump? Or my virtual device should always handle both ump and legacy format? Or I should prevent the legacy device to connect to the ump endpoint?

Please let me know if anyone needs more info for the questions, or if the question is duplicated so that I could referred to the existing discussion.

What I built. A small PE responder (running on a Mac) that impersonates a sound generator. It serves resources built from data that a synth already has — its parameter names and its CC map — so that a hardware controller can discover it over MIDI-CI. The result: the controller auto-labels its eight knobs with the synth's real parameter names and drives them, with no MIDI-learn and no templates. The two products were never designed to interoperate; PE made them.

For me this was the "oh, it actually works" moment — the thing PE promised, running on real gear. It scaled cleanly across ~47 instruments from one software collection.

Why I'm posting. Getting there took more reverse-engineering than I expected, and I ran into a few things I'd genuinely like other implementers' perspectives on:

1. Standard vs. vendor-specific resources. The controller I used fetches vendor-specific

   parameter/value resources rather than the standardized CtrlList / AllCtrlList. Is that common in the wild? Has anyone successfully served standard controller resources to a shipping controller and had it map knobs from them? I'd love to know how portable a "standard-resources-only" responder actually is today.

2. Subscriptions / value sync. For a responder to advertise live values and have a controller

   display them, what's the subscription behavior you've found works reliably? I'd like to compare notes on the full vs partial update flow and how different peers handle it.

3. Robustness patterns. Stale MIDI-CI sessions, re-subscription behavior, MUID invalidation on

   reconnect — is there an agreed set of best practices or, ideally, a reference implementation people build against?

Offer. I'm happy to share the responder and the harvester (the bit that turns a synth's shipped files into a PE resource set) as a reference — it might save the next person the reverse-engineering, and it could be a useful starting point for anyone building a responder. If there's interest in an open reference implementation / conformance-style test set for PE, I'd gladly contribute what I have.

Mostly I'd love to hear from anyone else implementing PE — what's worked, what's been painful, and whether the standard-resource path is as viable as I hope it becomes.

Is there somewhere I'm missing on the forum or main TMA webpage that has a list of the current and past working groups? And possibly WGs being considered for the future for review or display of interest? Or maybe these are by invitation only? 

Thank you

As I understand it, there is a possible race condition around the initial baseline state.

For example:

1. The Initiator performs Get and obtains the current full state of a resource.
2. The Responder’s resource changes after that Get response.
3. The Initiator sends Subscription Start.
4. The Responder accepts the subscription and then starts sending Subscription Partial updates for subsequent changes.

In this sequence, the change that happened between the initial Get and the Subscription Start may not be observed by the Initiator, unless the Initiator performs another Get after Subscription Start to establish a reliable baseline.

From an interoperability point of view, it seems safest if Initiators are recommended to perform Get after Subscription Start has been accepted, and then apply subsequent Subscription Partial updates on top of that state.

Is there any plan to clarify this in the specification or implementation guidelines?

If this behavior is not recommended or required for Initiators, then as a conservative Responder implementation, I may need to send Subscription Notify immediately after accepting Subscription Start, in order to prompt the Initiator to retrieve the current full state.

However, if both sides behave conservatively, this can result in redundant Gets:

• The Initiator sends Get after Subscription Start to establish the baseline.
• The Responder also sends Subscription Notify after Subscription Start to prompt a Get.
• The Initiator may then perform an additional Get because of the Notify.

This is not necessarily incorrect, but it seems inefficient and could lead to inconsistent implementation patterns between devices.

So my questions are:

1. Is the intended/recommended behavior that an Initiator should perform Get after Subscription Start has been accepted, in order to establish a reliable initial baseline?
2. If so, would it be appropriate to clarify this as a recommended practice in the specification or implementation guidelines?
3. If not, what is the recommended Responder behavior to avoid missed changes around Subscription Start?
4. Should a Responder send Subscription Notify immediately after accepting Subscription Start, or should it avoid doing so to prevent redundant Gets?

My main concern is ensuring that the Initiator and Responder can share a complete and correct resource image without relying on implementation-specific assumptions.