ilmenator

Could you add a link here?

2 semi kits left.

Hi all, I finally realized that I will probably never get around to building these babies: up for sale are three AOUT semi kits consisting of 1x MBHP_AOUT_V1 board 2x MAX525BCPP 1x MAX6007BEUR each. The AOUT module provides 8 control voltage (CV) outputs with 12 bit resolution and 2 gate outputs. It is used by various MIDIbox projects to control analog synthesizers and/or FX gear. All other parts that you'll need for fully populating the boards are easily available at Reichelt. Please note that these are double sided boards that follow the original layout exactly, except that you don't need any bridge wires. Asking price is 35,- EUR per semi kit plus shipping, or make me an offer - I think back then I paid 50,- EUR per pair of 525s alone... I'll be travelling to Germany beginning of February, so for extra cheap shipping I could send them from there. PM me if interested - ilmenator

Here is the updated list for the upcoming batch of TPD boards: 2 | gtxdude 1 | mokomo 1 | Marxon 1 | BlondGuy 1 | electrodancer 2 | ken 2 | Dangerz They should be here in about two weeks or so. Please adjust your "Notification Options" under "My Settings" such that you are notified (e.g. by email) when I send you a PM once the boards have arrived. Thanks guys!

Ideally with IIC line drivers for studio cable lengths, see http://www.nxp.com/documents/application_note/AN444.pdf I volunteer to do a board layout for this.

It seems that my concerns about the cost of the OEM board is perceived as unfair criticism by some - that's why I'd like to explain why I think that the KissBox OEM is (edit: maybe) not a solution that fits my usecase. For others it might be the perfect solution. I have about 25+ years of experience with good old MIDI. I say this to justify that I have collected a good number of MIDI gadgets over this time. That's why I am in the process of designing a huge, modular, programmable MIDI patchbay, partly based on MIDIbox. However, with Benoit and TK introducing KissBox OEM integration into MIDIbox land, I discovered that RTP-MIDI has potentially solved the same problem already that I am working on: making sure that MIDI signals sent out by a certain device reach another device in the "network". Using RTP-MIDI, one would simply not need a hardware patchbay, because it is inherently there already. However, all the nice gear I have is not RTP-MIDI-ready. If I wanted to continue to use that "legacy" gear in an RTP-MIDI based setup, then I need to find a way of translating traditional MIDI into RTP-MIDI. I don't need additional features that my legacy MIDI gear doesn't understand anyways. I don't necessarily need this to be MIDIbox based either, but I'd surely love to because it is a platform I am quite familiar with. Let's say I want to integrate about 50-60 legacy MIDI devices. So far, this seems to be a costly endeavor using KissBox OEM boards at 100,- per each (edit: 8 16) devices for the RTP part alone (add MIDIbox hardware to that)... Benoit said they chose a microcontroller that has many more features - so I conclude there must be cheaper ways to achieve what I want. I do believe there is even a market for my usecase :smile: . It also looks to me a bit like a hen-egg problem: RTP-MIDI will have a hard time taking off if there is not enough momentum. It's going to be hard to sell that technology if there are not enough compatible devices. But then again, manufacturers will only jump the train if there is demand from customers (us). I sincerely hope that NAMM will be a success for KissBox and RTP-MIDI. Edit: Benoit corrected a typo, so that actually halves the cost and reduces my concerns significantly! Now I only need to find out where to connect a third IIC chain for the remaining 4 MIDI I/Os. Could PA8 and PA9 (IIC3 on STM32F4) be made available for such a task? Adding to a total of 16 physical MIDI I/O ports on the MIDIbox (4 UART based via J11E, 12 IIC-based via 3 IIC chains with 4 I/Os each)? Nothing but the router functionality has to run on the core...

Just a quote from rtp-midi.com: "RTP-MIDI is also implemented on embedded computer platforms, since the required memory footprint and processor usage makes it compatible with modern microcontrollers for a low cost." Raspberry Pi or even lower cost machines?

He clearly said "remove the empty lines" - I read from that that he does not refer to the last line exclusively...

But RTP-X requires an RTP-OEM module in the first place, because it is only an addon, right? Which means it will add even more costs? I'd really like to see a low-cost version of this - without the fancy "much, much more than sending/receiving MIDI" features that we will eventually see implemented on your current hardware.

So to be a bit more specific: imagine an RTP-MIDI equipped SEQv4. If it is LPC17-based then I can hook up 6 MIDI-synths to it, using the regular I/Os plus the IIC ones. The seventh "device" is MBSEQv4 itself, and that means I could potentially connect another single MIDI device if TK added that option (or is that already supported?). Is that how it can work? And then, I would need another MIDIbox with Kiss-Box attached for the remaining synths?

This is what I have been trying to get my head around: How do you connect your MIDI-interfaced synths with the Kiss-Boxes (or RTP-MIDI in general)? From what I have seen so far: having a significant number of MIDI-capable hardware synths already does not make RTP-MIDI any more attractive. That's why I was asking for specific application scenarios in order to see how much (yes, in the end it's down to cost again...) for this brave new world one would have to shell out... Having all those MIDI hardware devices, I would want them all to be part of the system. I have an infrastructure in place today - it's not perfect but it works. I can see the benefits of RTP-MIDI. Now, how do I make sure these benefits are also shared with the legacy devices?

Yes, totally go for it - that was my reasoning as well, and I have not been disappointed. Actually, before using KiCad I tried a special version of Target which allowed for more PCB real estate, but was limited in the number of pads it would accept - another crippleware attempt. I am so glad I moved over to KiCad quickly :-).

Thanks Benoit for the overview - I got what you explained from reading through the Wikipedia page that you linked to in your first post. When saying that I am confused I was rather refering to the different versions of KissBoxes I can find on your website, and what features (you seem to be referring to those in different terms, like SPI "firmware", UART "software") they support or not, and whether these are changeable by software (apparently, they are not). Apart from the list of advantages that Thorsten gives - what are the arguments you would put forward in favor of RTP-MIDI, and in which application scenarios do you see it being used, considering the price tag for RTP-MIDI modules you are mentioning? Good luck at NAMM!

Well all that is rather confusing - I see a lot of potential but it is unclear to me what features are there for which version, and how these different versions integrate in a traditional MIDI setup. It's easy to imagine a box with 16 physical MIDI ports that transforms those signals to an RTP-MIDI stream. But then I would need at least one "decoder" at the other end. As far as I understand, a KissBox OEM would allow a single MIDIbox to be integrated into an RTP-MIDI network. Looking at the picture above it must be a per-piece price, and I'm quite shocked. Given that you need at least two of these (or similar) units, that amounts to a significant sum for a minimal setup... I'd love to be corrected, though!

How many physical MIDI connections can I replace by a pair of KissBox OEM devices?

Apart from the smaller footprint I cannot see any advantages of the Cerb40 over the STM32F4-DISCOVERY kit: twice as expensive, fewer IO pins available, and less widespread :-/. Maybe outside of MIDIbox land the FEZ Cerberus software can be useful, but here it does not play a role at all.

And will there be a DIY version, similar to what we have for the GM5?

Almost everything you will need in MIDIbox-land is available, but you need to understand the library concept of KiCad. I prefer the very nice libraries by Walter, you can find the here. Also, it is pretty straight forward to create your own components if necessary!

Some of you may know that I am a big fan of KiCad, a free PCB design tool. One of the areas in which KiCad was lagging behind other tools like Eagle was visualization of created PCBs with components. This can be extremely helpful when you have highly packed boards with many components placed close to each other. You don't want them to overlap mechanically, because that will cause a problem when you try to solder them... Since a few weeks, there is a very nice and free extension over at sourceforge that provides very decent renderings of PCBs created with KiCad, and - if you have the component models - with the components placed: kicad 3D. Just a few examples here: Maybe that will inspire some others to give KiCad a try!

Because it's 20 years older and a totally different thing. Because it's probably embedded in a proprietary way, encapsulated in a SysEx string? You could volunteer to write such a tool if you can't find one!

Random MIDI-Notes hören sich in jedem Fall stark nach offenen Eingängen an.

The ones used by Wilba on the MB-SEQv4 come to mind - Re'an P401, but AFAIK they are not produced anymore. Maybe there is some NOS somewhere?

My point is that adding these features would make the rather complex configuration options even more difficult to grasp, leaving those willing to start in MIDIbox land even more confused than what they are already. Speaking of community, I guess part of the things to be considered here is how much the community would actually benefit from these additional parameters, if there is a single person with a proprietary hardware - and why shouldn't that use proprietary code to run? But, TK already answered this, so who am I to speak for him :smile: . It's just my personal take on this and I might be totally off...

No offence meant here, but reading your first post again it seems that the problem you ran into here (and which requires the solution you pointed out) actually is a particular one, caused by misinterpretation of the available documentation. Maybe it is better to invest time and forces into the improvement of the documentation then, instead of blowing up the complexity of the system itself?

:smile: