Jump to content

rvlt

Members
  • Posts

    164
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by rvlt

  1. Working perfectly! Thank you!
  2. Thanks Duggle, maybe easy wasn't the right word, it is actually super easy to do. I just wanted know if there is already an existing poweron-snapshot function. re. the value-property: it doesn't work well with analog pots because the value you send doesn't correspond to the real pot. Seems that for the snapshot dump to work you have to move an analog pot to write it's value to some kind of buffer(?). If you don't do it the buffer is empty (values=0).
  3. Is there an equivalent to the snapshot_at_poweron function in MB_NG yet? I'm looking for a possibility to send the values of my analog pots and switches after startup... I played around with the snapshots and assigned a switch to the dump function in my default.ngc: EVENT_BUTTON id= 4 type=META meta=DumpSnapshot this indeed sends a snapshot, but all values are set to 0. if I start turning pots and dump the snapshot again, it works. What am I doing wrong here? ---- For an automatic snapshot dump after boot, I could do the following: - set up a "virtual" button id (e.g. 20) in my default.ngc with the meta event stated above - in my default.ngr I could put this: trigger BUTTON:20 Is this the proper way to do this? Or is there already a more easy way that I'm not aware of?
  4. rvlt

    MIDIbox KB

    I ripped my wheels off an old miditech-keyboard, and another one from a m-audio oxygen8 V1 (was the same wheel assembly on both). Other than that I only know Doepfer who sell wheel / joystick combos: Doepfer - Accessories I once repaired a CME keyboard which had a special potentiometer for the pitch/mod wheels, it was from "Alpha" and had 90° printed on it. With these you get the full potentiometer range by only turning it 90° (centered). You could only get it from CME support for 10,- Euro / each. Pretty expensive. Cheers Lars
  5. **** SOLD **** I'm selling my MB Seq V4. I know i'll regret it someday but don't use it that much and need some money for other projects. It's based on a Core32 and Smash's Control surface PCB. It has two additional Midi Outs (so all in all 2x In + 4x Out), USB, Ethernet-Port for OSC and an internal Micro-SD-Card. I built a nice wooden desktop enclosure for it, the footprint is pretty small, think of a access virus desktop. The back panel is still missing, I was too lazy to do it, but I can make one before I sell it, or send an FPD-File. Everything's working perfectly and is in mint condition. PM me if you're interested. Cheers Lars
  6. Works perfectly!!! :thumbsup: :thumbsup: :thumbsup: Thank you!
  7. Hey, here are the values I measured. The pinrange was set 1700:2880 before, which gave me reliable pitch values from +8128 to -8192. I was alternating between up and down movements. 2274 2284 2271 2278 2280 2280 2269 2284 2283 2276 2268 2295 2283 2269 2286 2268 2266 2283 2287 2283 2275 2260 2273 2262 2257 2278
  8. I tried the AinSer-support for the mod- and pitchwheel and it worked great. But one small problem remains: the pitch-wheel is center-detended of course, and it uses a spring mechanism to return the potentiometer to the middle after you moved it. This is working quite well but it isn't 100% accurate, resulting in pitchbend values lesser or greater than 0. I'd think that every pitch wheel construction suffers from these (very) small pot movements, I wonder how other manufacturers handle this... Is there a way to solve this in software? Something like an extended deadband: all pitchbend values from normally, say -512 to + 512 should now output pitchbend=0. Would that be possible? Cheers Lars
  9. Hey, I did a few more tests: 1. I used a different macbook with a different PSU: same problem 2. I used an extension chord from another room (different fuse): same problem 3. I used our studio mac (mac pro desktop): all fine ! hmm … this made me wonder if this whole issue was related to grounding my macbook. So I tried the extension chord from my apple PSU, the one with three prongs (AC and Ground), and voila: When I use this I don't have any more problems. Seems that this is a common problem: http://www.kellerbude.de/threads/1728-MacBook-Pro-Gehäuse-steht-unter-Strom-Spannung TK, could you tell me which cable you used when you tested this? The three-pin (schuko) cable or the small two pin adapter? I really wonder how manufactures do it with devices which have a grounded case and a USB connector. Anyway, I think I should start looking for a 5V PSU Class II like you suggested. ==== regarding the midi connection: I also thought about this, but when I tried it I didn't have that issue. On (I guess) most devices the midi socket's outer ring is connected to ground, but the midi cables did not have the ring connected on both sides. I tried that with three different (non-selfmade) midi cables: they all had the 5 pins connected, but the outer ring was unconnected. The "real ground" on midi cables (middle pin 2) is normally connect to ground on midi out sockets, but "should not" be connected on midi in sockets. That's why I didn't have that issue with midi, only with a USB connection.
  10. Thank you guys, novski, there is no connection between these two points, they are isolated. I tried a different approach today: I disconnected the switching PSU and instead used a simple transformer in conjuntion with the LPC17 onboard PSU (I put in a 7805...). But the result was the same: As soon as I connect my macbook PSU, there is a 28V difference between "LPC17-Ground" and "Earth/Chassis Ground". I guess most people don't run into this problem because they either use USB power or external wallwarts. To make this clear again: As long as these two grounds are isolated, everything is working fine. Maybe this is normal? Don't know, but it still sounds weird to me... Anyway I won't use the direct USB connection from now on.
  11. Cool, though I have to buy a new MCP3208 to try this. I accidentally destroyed two of them today... :sad: :sad:
  12. Hey, today I accidentally destroyed two MCP3208 while working on my midi-keyboard. At first I thought some electrostatic voltage was the reason for this, but then I investigated further and realized that I had a strange +28V voltage measured between GND and the metal case of my controller. Ok, here is the setting: - I have a keyboard controller case with a metal top. It is powered by an internal PSU which gives me a clean +5V for the LPC17. On the mains connector the two AC lines and the GND are connnected to the PSU, and the GND is also connected to the metal case. - the PSU output is GND and +5V and is connected to J2 of the LPC17. The USB power option jumper and J1 are not even stuffed on the board. As mentioned on ucapps I made a bridge between the outer pins of the missing 7805. The LPC17 and all connected boards, pots, displays etc. run just fine. - When I connect the LPC17 to a (battery powered) macbook via USB everything is still running fine. - But as soon as I connect my apple power supply to my macbook, I measure +28V between GND on the LPC17 (or Ainser64) and the metal keyboard case. I just realized that because a GND wire coming from the AinSer64 was touching the case and destroyed the MCP3208 on the AinSer board, two times ... When I deconnect the macbook's PSU the voltage is gone. -> Where is my error? Has anyone an explanation for this? Is the keyboard PSU faulty, or the apple PSU, or my macbook? The solution for me is pretty simple atm, because I don't need the USB connector on that keyboard, so I could simply desolder it, although it is handy sometimes to quickly connect it to a computer. But If anyone could shed some light into this, please let me know.
  13. Hey, I tried it with my keyboard yesterday and all I can say is it works perfectly. No noticeable latency difference compared to MB_KB or to the original keyboard controller. Cheers Lars
  14. I have another feature request: It would be great to use some of the onboard-ports of the LPC17 as additional I/Os with MB_NG. TK already confirmed that J10 will be available for standard digital inputs, and it would be really handy to use J5a/b or J28 as digital outputs as well. Today I realized that I need one (!) additional dout pin for connecting a LED, so instead of adding another DOUT board (or breadboard one), it would be much easier to simply use J5or J28 directly. ----- BTW can anybody confirm this: I have a 3-digit LED connected via two shift registers on a DOUTx4: SR1 D0-7 are connected to the segments SR2 D0-2 are connected to the commons (no resistors installed) so SR2 D3-7 are free, but I can't use them for connecting "normal" LEDs, right? Cheers Lars
  15. Hey, here are my two controllers: >> Mini Controller (1x LCD, 1x Encoder, 8x analog Pots@AinSer, 3x Switches) Event Pool Number of Items: 12 Event Pool Allocation: 723 of 24576 bytes (2%) >> Tascam Remote (1x LCD, 1x Encoder, 66x small buttons via matrix, 9x big buttons via direct DIN) Event Pool Number of Items: 92 Event Pool Allocation: 6284 of 24576 bytes (25%) but this is not finished yet, still 137 LEDs via MAX7221 and 3x 7-Seg LED to do.
  16. Ah, right, I just saw the config parameters in your configuration example. Perfect. Now if only DHL's latency would be less than 7 days... :rolleyes:
  17. Great! I'm desparately waiting for another two LPCXpresso boards, I don't wont to rip apart my other controller again. But I will try this as soon as I get them, hopefully tomorrow... btw, provided that the keyboard extension works well, will you incorporate the calibration procedure for the mod/pitchwheel as well? Lars
  18. regarding the possible MAX7221 support: do you already know which port of the LPC17 you will use for this? AFAIK it needs a DATA IN, LOAD/CS and CLK (besides 5V and Gnd). I'm not in a hurry, just wondering how I do the internal wiring of my controller. Cheers Lars
  19. rvlt

    MIDIbox KB

    If there are two cables with DIL16 headers coming from your keybed, I'd say yes. Just order a DIO_Matrix module and give it a go.. ;)
  20. rvlt

    MIDIbox KB

    "Meifa CO., Ltd. © Copyright Keyboard-R" is printed on the backpanel. Maybe it's a Fatar clone or something..
  21. rvlt

    MIDIbox KB

    Hey, I've managed to install MB_KB today. I spent half a day to measure the matrix layout / connections of my old miditech keyboard, just find out that .... ... the two cables with DIL16 headers coming from the miditech match exactly the two DIL16 sockets on the DIO Matrix. So it is a 1:1 connection, I didn't have to resolder a single cable!!! That was really PLUG'N'PLAY!! Could have saved my about 5 hours if I just tried to connect them and see what happens, but anyway... :rolleyes: So far everything's working great. Ready to try MB_NG+KB ... :smile: Cheers Lars
  22. I can confirm that these LEDs and encoders from Segor Electronics (Berlin) work fine: - LED 3mm rot diffus 630nm 50mcd/20mA --> 6 Cent each for 100+) - PE16C-4015F-N0024 (Drehencoder 24/360' +Gew. D-Achse,h=21mm,nichtrast.) --> 2,32 Eur each for 10+)
  23. rvlt

    MIDIbox KB

    Hard to tell in theory. Do we have any numbers of other (commercial) midi keyboards to compare with? For me an added latency of max. 1ms still sounds fast, at least for normal (non-percussive) keyboard operation. I'm thinking of a real world example: Say you want to build a midi keyboard with a few pots, encoders etc., so you add a LPC17 with MBKB software for super low latency. Then you add another LPC17 (with MBNG) for the rest of the controllers. If you want to use only a single USB port (for convenience) to connect your computer, you would have to merge (e.g. via Midi I/O #4) the MBKB midi data with the MBNG controller data in the MBNG, right? Would this process also add latency, maybe even more than 1ms? So from this point of view a merge between MBKB and MBNG would be much more convenient, and performance-wise on the same level. But this is all (my) theory, maybe it's best to try it out: If we'd have a beta version of an KB-enhanced MBNG, we could compare these two and see if it "feels" different. (BTW I'm just waiting for my DIO_Matrix module to arrive from Smash_TV, than I'll try MBKB asap..) Cheers Lars
  24. rvlt

    MIDIbox KB

    The calibration feature for the wheels sounds great! Will an AINSer be supported for this as well? I don't trust the onboard a-d conversion of the LPC17 so much.. Actually the wheel calibration is one of the main reasons I want to upgrade my existing controller keyboard to a MB KB version. I had to change the pots of my pitch- and modwheels because they were worn out. I put in pots with the same values, but since every pot has a (slightly) different curve, they don't send the full range of CCs anymore and the mod wheels is jittering now quite heavy. There is no way of calibrating this, so... MB KB to the rescue! :smile:
×
×
  • Create New...