-
Posts
15,246 -
Joined
Content Type
Profiles
Forums
Blogs
Gallery
Everything posted by TK.
-
Jump to this article :) http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=news;action=display;num=1034254654 Best Regards, Thorsten.
-
Hi Stefan, This must be a problem between the MIDI Out of your PC and the MIDI In of your MB64. It seems that the sysex dump will not be transfered correctly. See also: http://www.ucapps.de/howtodebug.html However, for the first tests I could send you a modified firmware which is already configured for your equipment. No Port 0. The order has not been changed in the mbhp_core version Unused outputs can be left open Best Regards, Thorsten.
-
The SID gets hot, thats normal. It's just good old analog stuff! :-) If the SID hangs up, it might be the reason that something influences the data transfers between the core and the SID module. I mean that ESD issue... e.g. if you have a temperature regulated soldering iron which switches on/off sometimes, this can cause unwanted transients on the data lines which disturb the data accesses. Or if your mobile phone rings during a SID session, the data flow could also be disturbed. Solution: build the circuit into a metal case like known from "real" synthesizers... You are writing that the cutoff frequency of one chip cannot be controlled. I hope that this isn't a 8580? Best Regards, Thorsten.
-
It depends on the quality and from where you order the parts, from the way you mount the stuff (PCBs or vectorboards), from the enclosure, from the available tools... it's really hard to say. I would assume that a least-cost MIDIbox with 8 faders, 8 pots and some buttons, built on a vectorboard can be realized for about $30. But the total costs increase fast when you order the parts from different shops, when you also need a programmer (btw: I still burn PICs for free), when the required tools like soldering-iron, cable cutter, etc. are not available. It doesn't make a big difference if you build a box based on the MBHP design or on the old MIDIbox Plus design, because the cost-intensive parts (pots/faders/PIC) are the same. Best Regards, Thorsten.
-
Best experiences have been made with seperated AIN modules which are as close to the pots as possible (see also the pictures at the bottom of http://www.ucapps.de/mbhp_ain.html). All other modules can be combined to one PCB without any risk of unstable signals. You could also try to create a AIN board which allows you to mount the pots - this saves effort, but requires some experiences in layouting a PCB. Best Regards, Thorsten. P.S.: I hope that somebody else can provide some good links to soldering guides...
-
Hi, sure, this is possible on this way: LTC J1:MI -> MIDIbox Plus Rx Pin MIDIbox Plus Tx Pin -> MB64 Rx Pin MB64 Tx Pin -> LTC J1:MO Hope that this short description is clear enough (just compare the schematics of the MBHP core, the LTC module & MIDIbox Plus). I will draw a diagram if required... Best Regards, Thorsten.
-
Hi, you just only have to take care for the different voltage domains (9V / 12V). If you create a single PCB for both SIDs and cores, you have to stuff one 7812, one 7809, one 7805: both cores and both SIDs can be supplied by a 7805 The 6581 additionally by a 7812 The 8580 by a 7809 15V should be ok for all 78xx in this configuration Best Regards, Thorsten.
-
Hi Kieran, With the next update there will be no difference concerning the external functions (64 pots, 64 buttons, 64 LEDs), but the implementation differes a lot. In the MB64 firmware, 128 bytes are used to store the MIDI event for every pot in RAM... the fast access to the "events" is required to handle incoming MIDI events for the soft-takeover function (snap mode, etc.) in realtime without dataloss. The MB64SEQ firmware supports soft-takeover only for internal events - this saved me from storing the events in RAM, and so I was able to use the free memory for two additional layers (see sequencer concept in the news section). The MIDI events itself are saved in the slow flash memory (slow means: ca. 5 uS read-access delay) I wouldn't do this - so long as the "snap" mode is not required, the MB64SEQ can also be used as common MIDI controller. Every track can be switched to "controller" mode, where every pot sends the event immediately. Also mixed configurations are possible (n tracks as sequencer, m tracks as controller). My suggestion: just use two BankSticks for the different purposes. One stick should be prepared for controller functions, the other for sequencer functions. :) Best Regards, Thorsten. P.S.: with the MIDIbox NG design, all these limitations will be obsolete :)
-
solange nur die Bauteilkosten und der eigene Aufwand verrechnet, und die Copyrights nicht von den PCBs/Firmwares entfernt werden, bin ich damit einverstanden. Gruss, Thorsten.
-
Die Reihenfolge der LEDs ist fest vorgegeben und kann nur durch Umloeten geaendert werden. Button 1 entspricht LED 1, usw... diese Zuordnung darf allerdings nicht mit der Reihenfolge der Schieberegister verwechselt werden. Die DIN-Register 1 2 3 4 5 6 7 8 entsprechen den DOUT-Registern: 2 3 1 4 5 6 7 8 Diese etwas seltsame Reihenfolge habe ich deshalb so gewaehlt, weil viele MIDIboxen mit lediglich 16 LEDs bestueckt sind, und die Navigationstasten an DIN.1 nicht unbedingt beleuchtet werden muessen. Gruss, Thorsten.
-
Fine :) I will grab some of the photos next monday (I'm currently quite busy... no, not for any MIDI project ;-) Best Regards, Thorsten.
-
no, everything is 1:1 hardware compatible, no parts beside of the PIC have to be exchanged. I'm only unsure if the JDM module can be reused (still waiting for inputs ;)) Best Regards, Thorsten.
-
Hi Rogic, the error messages can be ignored; the DRC test notices that the font used for the copyright overlaps the GND area, but this is ok Best Regards, Thorsten.
-
No, this isn't possible with MB16E, but it will be supported by MIDIbox NG where encoders and buttons are sampled on the same shiftregister chain. However, there is a workaround: if you plan to build a DINX4, and want to connect (lets say...) 8 encoders and 16 buttons, you can cut the SO; SC and RC track between IC2 and IC3 and connect one half to port J7 of the core module (encoders) and the other half to port J9 of the core module (buttons). Just handle it like 2 seperate DINX2 modules... (the power tracks have to be connected only once) Best Regards, Thorsten.
-
I've planned to integrate 4 analog CV outputs and 4 triggers so that such filters can be controlled from the SW implemented generators (LFOs, envelopes) and via CC. :) Best Regards, Thorsten.
-
Hi, Yes, it should be enough space. Also for a complete pot/button configuration w/o MIDI Learn.... it's in my ToDo list :) yes Best Regards, Thorsten.
-
This is definitively the MIDIbox of the Week! :D Best Regards, Thorsten.
-
Hi, you could search for your local ALPS distributor. Alps manufacturs many kinds of pots and faders, detended types should also be available... http://www.alps.com Best Regards, Thorsten.
-
Hi Rogic, I'm only using the Linux version of Eagle, but it should also work under Wintendo: select File->CAM Processor, load a predefined job (Gerber) and change the printer device for the "solder side" tab to "PS". Finally click on the "process section" button. (.eps is a compatible variant of postscript .ps) Best Regards, Thorsten.
-
Hi Dave, This is really a critical issue. Currently only two screens are visible (if you are not in the menu). One main screen if no pot is moved: which shows the selected layer, bank, sequencer position of the current track, a track overview (selected/muted) and in the second line an overview about the muted pot columns The second screen will be activated when a pot is moved: the values depend on the MIDI event type (here: Note event), Track Mode, etc. I think that for an encoder solution a larger display is mandatory, which should show at least the status of 8 encoders - here for Layer A (assigned to Note Number), B (assigned to velocity) and C (assigned to Gate Length) of Track 1: Maybe it makes also sense to show the note and velocity (as moving bar) at once... however, I've planned a "Display Plug In" feature for MIDIbox NG which would allow everybody to design his own screen layout (your private MIDIbox skin... ;-)) I develop on my ultimate MIDIbox since four years and fortunately find enough time for my job, leisures and other pleasures ;-) Here: :-) http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=news;action=display;num=1034254654 Best Regards, Thorsten.
-
Hi Rogic, yes, it runs with the "old" PIC16F - after I removed all the dedicated routines for motorfaders and the sequencer, I had enough free memory for some new extensions. And I think that I will add some more features in the future, for example some predefined meta events which simulate a "mute channel" and "solo channel", and a function which allows to define pot/fader groups. But before the other firmwares will be updated. Best Regards, Thorsten.
-
I think this is not really the final version - but it's running fine :) http://www.ucapps.de/midibox/midibox64_v100.zip Changes: Sequencer and Motorfader parts removed Support for 64 pots, 64 buttons, 64 LEDs a device ID from 0 to 7 allows you to address up to 8 MIDIbox64 in a long MIDI chain Device ID and MIDIbox-to-COM option can be patched directly in the .hex file (see README.txt) navigation buttons can be optionally disabled these 4 buttons are automatically disabled if no LCD is connected 5 new display modes banks can be named MIDI time code (MTC) will be displayed at page #5 several minor bugfixes and improvements new mk_syx script and MIDIbox64 editor See also: http://www.ucapps.de/midibox64_changelog.html Thanks to Serge for the good cooperation in the last days regarding the editor updates! :) Best Regards, Thorsten. P.S.: the MIDIbox16E and MIDIbox MF will be updated with similar features in about 2 weeks
-
Hi, This is not quite correct - currently you need 3 cores for the MF section and one core for the encoder section. And thats all - these cores have to be connected in a MIDI chain. The MF firmware as well as the encoder firmware support 40 buttons/LEDs and in the future 64 buttons/LEDs, so that an "main core" for additional IOs is not required. LCD: for motorfaders you don't really need a LCD, for encoders it makes sense. If sometime the MIDIbox Link works (I haven't started to evaluate this solution yet), it will be possible to display informations of every core at one central LCD. In an unreleased MF version (*) I realised SFB events to stop a fader. These events can be assigned to button inputs, so that you can: a) use buttons to stop faders (one button for each fader) b) use capacitive touch sensors instead of buttons (*) I don't release immediate beta versions, but they are available via mail If you have programming skills, you can try to develop something near it with a bigger PIC (see the Microchip page for the wide choice)... from my experience it makes no sense to spent a lot of effort just to save one PIC which costs you about US $8 ;-) Best Regards, Thorsten.