Hardware Blocks. ADC included or separated?

[Susorl]

I will start with some discussion. The big question that I have here is related with the main blocks of the Hardware. I think that we have Analog Audio Signals (of multiple kinds), that we want to convert to MIDI2.

But, MIDI is entirely a Digital realm, and that could be considered a Big Block itself. Also, conceptually, it receives Digital Audio Channel of a given quality, and basically with the Hz Pitch Detection Algorithm like main Software, it will generate MIDI data.

Initially, is always needed the presence of ADC circuits in some form. That's the other Big Block on this. It could be reduced to a minimum in order to send the sampling data to the algorithm directly and operates the result, that means that is integrated on the other Block and it's closed hardware/software.

But, in my opinion, it's possible to separate clearly both BIG parts, and create Transmission system of the Digital Audio Channels using some protocol.

The problem of this approach is that on this form, the Project becomes 2 independent Projects, and that's the first Discussion that I want to launch. What's your opinion about this?

This is also related with what's needed to be embedded?

Thanks, and I agree that any opinion would be valuable.

[djowel]

Before announcing this, I had already implemented the hardware for all the major building blocks, except for the MIDI component. I am currently using the Hz pitch detection system in various consulting applications. Note that, for practical reasons, I'm using the MCU’s SAR ADCs, which are perfectly suitable for pitch detection, though not of audio-grade quality for use as an audio interface, as you mentioned.

To be clear, this is not an audio interface project, nor should it be for practical reasons. Including such functionality would, in my opinion, unnecessarily complicate the design and significantly increase the cost.

[Susorl]

Yes, I agree with the practical reasons. In fact, the project like it's proposed, it will be the practical way to build MIDI controllers based on physical String vibration, like an alternative to keyboards. With one device like this, the development of different kinds of MIDI controllers would be easy for everyone. I'm fully on this because of that.

But, this discussion is a way to explore and explain the ground base hardware blocks. And it's good to maintain certain independence, but if we look to your Infinity project, we have the same initial blocks probably, MCU's SAR ADCs, and same Pitch detection software. We can say that we send Analog signals to one device, (Infinity) and first ADC and MCU, in parallel we send analog signals to another device (Hz to MIDI) and second ADC and MCU, and in paralell we send the same analog signals again to an external device (Interface) with their own ADC and CODEC in this time. Writed like this, it sounds like not very logical, but it's true that this is still the best practical way to do it. I understand it. Probably it's more simple and cheap in fact.

We know that an interface is composed of a lot of different blocks (normally it has Preamps, ADC's, DCA's , CODEC, Audio Outs, MIDI IN/OUT, etc...) It's a GENERAL device.It looks like a practical device, but for me it's a very NOT a practical device (for ONE musical instrument).

Of course, ideally, talking about instruments like guitar, the target is to have only one ADC just after the pickups, and the Audio Grade quaility it's not these days a big issue. The problem comes after the ADC, because it's needed a protocol (CODEC) in order to send the digital TDM data from the ADC's in some comprehensible way to everyone. The advantage is clear, the software of Pitch Detection runs only once, and the Metadata could be used anywhere at any time (Infinity, MIDI conversion, Digital PostProcessing, etc...). But, don't take this too seriously, because I know that this is not achievable in an easy way, and it implies a complete paradigm change.

For the moment, it's good to focus on the project of Hz to MIDI in order to create a simple device that could be easily implemented in any instrument. It's almost there. I will create another discussion about the MIDI component that is pending.

[Susorl]

I know from University times (30 years ago....wow), the fundaments of C++, but never going deeply on it. I will try to use on MAX/MSP the C++ code of your algorithms, or trying to adapt it, i'm not very familiar, but it's possible. There is the object named gen~, that is a sample-level funtionality, and it's like a running subprogram almost like C++. It's good opportunity to start with. It's auto-compile mode.

Ok. Let's start, and please correct me if I'm wrong:

1 Pitch information
2 Onset and offset information, including attack and release velocity
3 Signal envelope
4 Gate information

This sounds good. Just to clarify, we want to use the MIDI protocol like a valuable way to send these .

The 2. Onset and Offset Corresponds to the Note On-Note Off message, Velocity is the main parameter , together with Pitch (or Key Note Number, or MIDI Note- that is a Frequency -or Pitch ,
These are events that are happening i a given Time, specific. The classic MIDI 1.0 is perfectly valid here.

That it needs to be differentiated with the 1. Pitch Information. or 3 Signal Envelope, These are more related with MPE capabilities, and maybe it's possible to define something here, but I'm not sure about compatibility, ?

4 Gate Information, what's exactly this, in relation with MIDI and this context?

Independent of this, it could help this recent Library Ni-Midi2 ( It's not Nu-MIDI2 but almost...je je)

https://conference.audio.dev/session/2024/introducing-ni-midi2/

https://github.com/midi2-dev/ni-midi2

Ok. I will go to a different discussion after this.

Thanks.

[djowel]

The 2. Onset and Offset Corresponds to the Note On-Note Off message, Velocity is the main parameter , together with Pitch (or Key Note Number, or MIDI Note- that is a Frequency -or Pitch , These are events that are happening i a given Time, specific. The classic MIDI 1.0 is perfectly valid here.

No they are not necessarily the same. You do not necessarily want to trigger a note-on/note-off, the way the keyboard does it. A note onset, for example, can be the start of a legato run. Unless, of course, if the sound patch has a way to dynamically switch on legato mode (MIDI CC 68) —which brings up an interesting topic in and of itself. But more importantly, at the note-onset, the pitch has not been determined yet, and so the note-on information, which requires pitch, is not yet complete.

[Susorl]

Yes, the fact that Note-On information, requires pitch (that happens normally after Onset), it's not too bad, because acts like a confirmation mode of the Action (Note). Also, probably it's needed more extra- time for extra-confirmation, before the Note-On message

The dynamically switch to Legato could be interesting, but probably like an optional feature (difficult to say if it's an effect or really translates better the reality?).

In any case, during legato run I suppose that the Pitch detection becomes the only way to confirm the Action (Note), or not? Is it the On-Set algorithm still detecting something allways (every note)? How you determine the transition, especially after Pull-Off?

[djowel]

In any case, during legato run I suppose that the Pitch detection becomes the only way to confirm the Action (Note), or not? Is it the On-Set algorithm still detecting something allways (every note)? How you determine the transition, especially after Pull-Off?

It gets very tricky, technically speaking. There's not enough space here to explain, if that's what you are asking. But here, have a read: https://www.cycfi.com/2021/01/onset-detection/

Quoting myself: "Real-time onset detection is a tough nut to crack. I did not realize that onset detection is still an active research area before I tried to implement it myself. "

[Susorl]

Thanks, Joel.
Quoting myself: ""In fact you have done over the years the complete development of what is needed here. And it's prepared and ready to be implemented.""

[brotherdust]

In a related note: it would be very cool to see this functionality as an add on to the Nexus. I've been shopping around quite a bit for a compact interface that can take 6-12 inputs. Most of what I've found is either too large, doesn't have enough of the same type of input (1/8" TRS preferable), too expensive or just has a lot of stuff I won't use.

The closest thing I could find was this, which looks promising, but it's not out yet.

[djowel]

In a related note: it would be very cool to see this functionality as an add on to the Nexus. I've been shopping around quite a bit for a compact interface that can take 6-12 inputs. Most of what I've found is either too large, doesn't have enough of the same type of input (1/8" TRS preferable), too expensive or just has a lot of stuff I won't use.

The closest thing I could find was this, which looks promising, but it's not out yet.

It seems this comment conflates two functions into one: 1. Audio interface 2. Pitch to MIDI. Take note that the modularaudiotools you linked to does not seem to have audio to MIDI functionality (Having MIDI in/out does not automatically mean having audio to MIDI capability).

[brotherdust]

In a related note: it would be very cool to see this functionality as an add on to the Nexus. I've been shopping around quite a bit for a compact interface that can take 6-12 inputs. Most of what I've found is either too large, doesn't have enough of the same type of input (1/8" TRS preferable), too expensive or just has a lot of stuff I won't use.

The closest thing I could find was this, which looks promising, but it's not out yet.

It seems this comment conflates two functions into one: 1. Audio interface 2. Pitch to MIDI. Take note that the modularaudiotools you linked to does not seem to have audio to MIDI functionality (Having MIDI in/out does not automatically mean having audio to MIDI capability).

You're right. Please accept my apologies and allow me to clarify.

Based on reading your articles, I had it in mind that Hz was software only.
As such I was curious what most people are using to get the audio into a PC for processing, in this case for pitch to MIDI.

I see in this thread you are considering hardware blocks, which is very cool indeed; but it seems to me that until such hardware is readily available and for maximum flexibility, software is the only option. Hence why I was asking about an audio interface. That's not to say I don't desire a hardware solution, simply that it makes more sense to me to have an "official" audio interface, as it were, for the Nexus so that those of us who wish to work with you to develop Hz are all working from a common standpoint.

Thank you again for being so generous with your time!

[Susorl]

Thanks for the link of MAT (Modular Audio Tools), it's not out yet, but you are right that it looks promising, especially the size and the Line inputs that could be connected to Nu pickups easily. (Still, the 8 outputs or Midi in/out would be not necessary in my opinion. But, it demonstrates that an 8 channel version of USB compliant (and Audio quality grade) is possible to realize with a footprint of 80 mm x 40 mm x 10 mm. And probably below 100 $ cost. That's an interesting moment here.

And that opens a clear debate about where to Run the Software of Hz. Hardware (Digital) and Software (Digital) are always two sides of the same coin, In which moment the digital realm transcends the analog view resides the BIG question.