seppoman

Surprise Surprise, Seppoman is in the house and posting :) I have uploaded the .SCH file to my server (the Wiki tells me that this file extension is not allowed...) http://www.seppoman.de/aout_ng/mbhp_aout_ng_r1.sch The link is also added to the NG Wiki page.

well you can play the drum sounds on the keyboard, so yes sure, why not?

Well 20V for several minutes and a funny smell doesn't sound too promising... While the DAC is not especially easy to kill, it is quite possible to kill it (I did that myself some years ago ;)). My advice for desoldering, if you don't have special equipment like low melting point solder metal or a hot air rework station would be to carefully cut off all the legs from the DAC alongside the IC body using a sharp carpet cutter knife and gentle force. Take care that you don't apply too much force, push towards the PCB, not diagonally to keep the pads from being lifted off. As soon as the IC body is removed, you can wipe away the separated legs from the pads using the soldering iron - use moderate heat for short durations and move them away towards the IC center, not the other way round again to preent the pads from being lifted off. Good luck, it can be done, so at least try a repair before you throw everything away :) S

A combined PCB is a nice thing and TK and me discussed it in the design phase of the ETH and SDCARD module. But the decision was made against it because separate modules are much more flexible in several use cases. E.g. I guess that other than for the fun of trying it out, not more than 10-20% of the MBSEQ builders will ever use OSC/Ethernet in practical work, maybe SD cards might replace the Banksticks for other projects in future etc. Plus panel placement is more flexible if you're not using premade cases (as a sidenote, I think it's a bit sad that all these hundreds of kit builds of complete projects are killing the design creativity of the community nowadays, but that's another story and only a rant from a long time member :whistle:). If some time there'll be something like a complete MBSEQ kit, such a combined PCB might make sense - although I'm wondering why we shouldn't do a complete SEQ "Base board" instead that contains Core 32, SD, ETH and all connectors (maybe even additional I2C MIDI outs etc?). But all this is a bit premature as long as not even the CS PCB is available (nudge nudge W ;)) S

So is your problem making the filter oscillate or getting a playable/tuned oscillation? Playing well-tuned oscillation isn't as easy as just setting everything to max and play :) The mbsid parameters routed to some target (like cutoff) add up together, so if you set cutoff to max, you're already at the top frequency limit. What you need to do is set keytracking to 127, i.e. output value will track the keyboard position, and then the (initial) cutoff value will be your "master tune". Getting a nice result requires good calibration and some tweaking time. S

P3/P4 are for the breakpoint. This setting is only meant as a starting point and doing measurements there won't give much reasonable readings. Just try the "mechanical" approach - these trimpots usually have 22 turns from one end to the other, so if you turn the trimpot in one direction until it starts making a clicking sound and then turn it back about 11 turns, you're fine. yes please do worry :D The SSM module doesn't have any means of adjusting gain and offset of the cutoff, so you will need to use the respective trimpots on the NG to calibrate/tune the filter cutoff. S

well the main.asm is part of the source code of this J5 DOUT example application. To apply any changes here, you'll need to compile the project in order to get your changes into the main.hex file you upload. S

I've used a different model back then that has only a classic parallel interface. My old MIOS8 driver can be found on www.seppoman.de. Recently I've tried to do a VFD->Hitachi emulator for these VFDs using an AVR controller, but discovered that keeping up with the needed response times is quite hard... Your VFD looks like it already has built in "Hitachi emulation", i.e. what they call M68 mode. I've also tried some Noritake VFD with emulation interface, and it had some compatibility problems in 4 bit mode, plus it is quite slow, just like the old Futaba one. But I think speed issues are not too much of a problem anymore under MIOS32 because of the underlying RTOS/task management. Good luck from one VFD fan to another :) S

Uhm, I see I should really get started with doing more docu... as a general rule of thumb you can assume that everything that doesn't specifically mention a bipolar control voltage will expect an unipolar CV. In the case of this module, IIRC the dynamic range of the regular CV range (0 .. 11.67V) is about 65 dB, with 0V being "silence" and 11.67V being unity gain. I have never thought about what happens if you apply a negative voltage to the CV input... Regarding your "+ GND -" reasoning - Although the docu doesn't exist yet, one might assume, also by comparison to the 2044 module, that this module will not be powered by love and fresh air :whistle: So J5 is obviously the only connector where you could come to the conclusion that it might have something to do with power supply. :tongue: Just like the AOUT(NG), the 2044 board, the MB_FM module etc, it expects a bipolar power supply of +/- 12 V and GND. Note also that generally a bipolar control voltage (CV) still doesn't mean that there are more than two wires involved, just the one signal can be above or below GND. S

I don't know how much the 5V part can take until it will fail instantly/later/get hot/... the 12V version is the right one. S

The link is for a G6K-2P-Y-DC12. Y means a different pin layout, latching would be G6KU. The G6K-2P 12V is non-latching and "normal pinout", so your question is answered by the part number ;-) Always try to match any part number precisely, then nothing bad can happen :) the correct Mouser number is 653-G6K-2P-DC12. It is a tiny relay that handles the bypass function. It's not really cheap but that's the price of the small size. I don't know of a suitable replacement, maybe someone else does? If you think it's too expensive you can either connect some standard (larger) relay to the PCB via wires or decide not to use the bypass function and solder jumpers. this is described on the wiki page. S

I am interested :) S

I have mostly used the Alps STEC16B3 type. They've got a very nice and smooth feel, quality seems fine although I've had a few heavily used menu encoders start jumping etc. But I guess most "consumer-class" encoders aren't built for eternity, if you want that you'll have to buy types in the 20 Euros/piece range ;) Wilba offered these chinese Alps clones, forgot the brand name, these are also nice although detented. I'm not too fond of the detent-removal thing, as the feeling is never the same as buying a non detented encoder from the start. Plus closing the encoder again never works as good as I'd wish so there's always a feeling that the part might not be as reliable as it was before. S

I've got about 10 pieces with integrated push button and 20 without. Got them from Smash some years ago but decided not to use them in any project because I thought they feel cheap when in original state and get even worse when the detent is removed... No idea what the original price was, let's say I'm asking 0.50 Euro each? If you want them just PM me your postal and paypal address :) S

strange, I've always had the feeling it's the other way round :ike: S

TK already told you - use a multi-port MIDI interface like e.g. the GM5x5x5.

What about the first link called "MIOS download" directly after the big letters FIRMWARE? :whistle: oh and while we're at finding the right stuff to read: this is the second pinned thread in this forum section :tongue: Anyway, welcome and happy midiboxing :) S

yes that's right. good luck and have fun :) S

no it's because it isn't done yet :tongue: While TK is truely a genius, he's still only a single person creating all this in his spare time. The only "finished"/beta project on the Core32 is the SEQ, and there's a variety of programming examples and fragments that can be used by programmers to do their own stuff. This change is a really big one involving a whole new architecture, thousands of new possibilities etc, so you can't have all that done in no time. And another reason why the HUI applications aren't done yet is probably that the processing power provided by the good old PIC is still good enough to do simple tasks like scanning a few buttons/pots and sending a few MIDI events. These apps like MB64 are mature and do what they're supposed to do so there's no real need to change over to the Core32. good plan - or you could simply try again using the good and stable old architecture :) S

I'm familiar with the TI DAC and planning to give it a try on a non-Midibox project one day as the datasheet looks quite promising. Didn't know the AD part so far. Comparing DAC specs is a very difficult task as there's always differences in measuring methods between the different companies, some specs are missing from some datasheets or given in different units or entirely different test conditions etc. From what I read, I'd say the TI part is better, especially looking at the AC characteristics like digital and analog feedthrough etc. settling time - that's irrelevant for CV generation. It would only start to become a problem if you'd want to generate a signal with several hundred kHz bandwith. For use in a NG successor/improvement, both parts have two major drawbacks. The first and most important one (at least if you'd want to not only use the module yourself but also give it to other people): TSSOP package! That's the same pin size and spacing like on the STM32. While I don't have any problem with soldering these, this package is definitely not at all newbie-compatible. The other issue is that both require 32 bit writes instead of 16 bits on the other AOUTs. This is probably OK on the Core32, but on a MIOS8 PIC with its bit-banged SPI output and performance already driven to the limits, it means double the effort on each channel update. Then you'd first need to find out (or better ask TK) if the internally processed data on the usual apps would even provide 16 bit data or not. Without the required data depth, using a 16 bit DAC makes no sense. But I think having 16 bits DAC would not give much benefit anyway. From the datasheet I'd say a real precision of the DAC output isn't much better than real 12 bits anyway, not only worst case but also in normal life, and in a usual DIYer setup the whole ecosystem like clean power, good layout (i.e. no single sided homemade PCBs), VERY short distance connections, shielded wiring, ground distribution etc is usually just not good enough to backup this precision, i.e. to have a general noise level in the system that isn't louder than any small value change. I guess maybe using the 12 bit model to save some money and avoid the need to care for different data generation/processing would make more sense. This way you'd get a more precise 12 bit signal from the better parts, of course without the coolness factor of being able to claim 16 bits precision. S

that's a semi-FAQ - short answer: As long as you're only using the NG in unipolar mode, everything is fine. in bipolar mode, the offest voltage will change without some modification. is one answer, although a bit outdated since I should probably document all this on the NG page when I find the time to update the official docu. S

Vss ist die Masse, also 0V, und muß dementsprechend an den "linken" Pin, wo der Linksanschlag ist.

very nice :thumbsup:

:tongue:

+1 for don't touch the autorouter :no: agreed - plus a VCC plane doesn't have important positive effects - GND planes provide improved GND impedance which is a good thing, but with VCC this doesn't really matter. That's right, alhough on multilayer PCBs, this is an intended effect, it works just like an additional smoothing capacitor and is completely free of charge (pun intended :D) S