732 replies to this topic

[cimo]

you need to login first! then edit, it s straight forward you can t miss it
Simone

[Kartoshka]

in 24 hours we got 245 units reserved..
noone ordered less than 3  ;D

seems like these cutes are in demand, you hungry midiboxers!

[Pascal]

I want 8 MIDI-Outs/Ins i need 8 Chips!?. 265 :-)

[Wilba]

I'm too slow to get my 10 in the first 250.  :(
I might have to steal stryd_one's 10.  ;D

[bugfight]

i'll trade places w/ wilba, he deserves it and will prolly use them first anywayz

[lief138]

I would give Wilba 50% of my haul.. then everyone could be happy

i'll trade places w/ wilba, he deserves it and will prolly use them first anywayz

[Wilba]

Thanks for the offers... I have such a backlog of stuff to do that I don't think I'll be needing them before a second bulk order.

[nILS]

"Second order?" Let's just wait another couple of days, maybe we get to n=2 ;D

[H2O]

Nice. +3

This chip sounds cool.  I'm keen to see the specs, I suppose they'll be released eventually?

[theprotool]

put myself down for 5.. cheers for this TK

[modulator]

some people have done mistakes at calculating the total amount
yesterday I have corrected the Total amount down and just from 302 to 286 again  ;)
The first chip from wilba makes the 250 full

[nebula]

I've often wondered, when you use a USB / MIDI chip like this, is it possible to get it talking to your PIC more efficiently than MIDI itself?  For example, could you build an IIC USB module that can act like multiple MIDI "cables"?  Can it communicate with a PIC at a faster-than-MIDI speed, which could allow for better timing?

[TK.]

I've often wondered, when you use a USB / MIDI chip like this, is it possible to get it talking to your PIC more efficiently than MIDI itself?  For example, could you build an IIC USB module that can act like multiple MIDI "cables"?  Can it communicate with a PIC at a faster-than-MIDI speed, which could allow for better timing?

In theory yes. In practice it can affect the architecture of the firmware. E.g., required MIDI In/Out buffer size, maximum allowed CPU load, interrupt priorities, etc...
MIOS and most main applications have been designed for MIDI baudrate. Using higher baudrates can lead to failures.

Best Regards, Thorsten.

[polosid]

what avr model is used for the gm5?

[seppoman]

what avr model is used for the gm5?

The only existing AVR with USB and TQFP32 package is the AT90USB162 http://www.atmel.com...sp?part_id=4097. But does that really matter? You need to buy this IC with preprogrammed GM5 firmware anyway

[polosid]

since there are many avr with usb, why the monome creators used a ftdi chip?

did tk ever cosidered to implement those chips in mbhp?

regarding gm5: did the creators write dedicated driver? is there a  standard tool like ez-usb for cypress?

what happens if i connect two gm5 to a computer?
and what happens in i try to connect two (or more) usb modules (cypress based) to a single computer?
i'm curios about the case in wich i build many usb midiboxes and i intend to use all these with a single computer...

[TK.]

since there are many avr with usb, why the monome creators used a fdti chip?

Just ask them, and please let me know about the reasons.

did tk ever cosidered to implement those chips in mbhp?

Yes, TK has considered this several times. There are at least three reasons why I don't find them suitable for MBHP:
- SSOP package, you are not able to solder this with a soldering iron
- expensive (because you need an additional adapter board SSOP->DIP (or similar) format)
- MIDI protocol not natively supported, a proxy is required which makes the usage complicated and error prone whenever you upgrade to an operating system which isn't supported by the proxy

regarding gm5: did the creators write dedicated driver?

Both: standard USB-MIDI and dedicated driver for windows (which hopefully fixes the known flaws which are documented at my website - I will test this)

is there a   standard tool like ez-usb for cypress?

You don't need a programmer, the closed-source firmware is already programmed into the chip.

what happens if i connect two gm5 to a computer?

We will see... ;)

As mentioned in my initial posting, I won't order the first batch before I tested the chip under Windows and MacOS

and what happens in i try to connect two (or more) usb modules (cypress based) to a single computer?
i'm curios about the case in wich i build many usb midiboxes and i intend to use all these with a single computer...

You will see multiple devices - the max configuration I ever tested was 3 MBHP_USB and 1 MBHP_USB_PIC module.
I guess, that for the GM5 chips it will work the same way...

Best Regards, Thorsten.

[polosid]

and what happens in i try to connect two (or more) usb modules (cypress based) to a single computer?
i'm curios about the case in wich i build many usb midiboxes and i intend to use all these with a single computer...

You will see multiple devices - the max configuration I ever tested was 3 MBHP_USB and 1 MBHP_USB_PIC module.
I guess, that for the GM5 chips it will work the same way...

Best Regards, Thorsten.

mmmhh... so there is no need to modify the driver, in cubase\nuendo i'll se many midi ports as many usb modules i connect to the pc. right?
i just plug a second module and it will be recognized..

regarding the general concept: if i actually build a midibox with usb it's like building two machines in one: a midi-usb interface and a classic midibox controller.
in the monome project (if i understand) midi (or osc) data is generated by a software (the driver that recives serial signals from the hardware device)

this solution transfers "complexity" from the mcu to the driver.
don't you think that all the pic-usb problems could be solved using such a configuration? so there re no midi issues at all before the driver

anyway i'll join monome forum to get more infos

[seppoman]

this solution transfers "complexity" from the mcu to the driver.
don't you think that all the pic-usb problems could be solved using such a configuration? so there re no midi issues at all before the driver

The big plus of the GM5 solution is that we finally have the chance to get an industy quality custom driver for a cheap USB-MIDI chip. If the "complexity" was transferred into the driver, this would mean we couldn't use this driver and a custom driver had to be made. A good driver is exactly the thing that was missing for the previous Midibox-USB solutions, so willingly decide to not use the original GM5 driver would be one of the most stupid things to do.

I'm wondering what's your motivation to question and complicate concepts before it was even fully tried out and tested? Can't you just be happy that a good solution seems near, wait like everyone else and then decide if that solution is suitable for your needs?

S

[polosid]

i was just curious, seppoman.
the questions i made regard general usb handling in diy projects, and are not strictly related to gm5 or to mios.

of course i'm happy about gm5 "as-is"
i only underlined that in a "monome like" solution you can freely handle midi, osc, qwerty or mouse control with less worry for mcu programming. i'm curious about the solutions in this direction