TK.

MIDIbox V1.74685 has been released as an interim solution for everybody, who is planning to upgrade to V2 later, which will require a PIC18F4685. A first alpha (incomplete) release of MBSID V2 can be expected in one or two months. Until then, just use this version and enjoy the new possibilities! :) This is the best "V1" ever released, because the MBNet approach speeds up the transfer of patches to the slaves significantly. WT patches are now directly edited in RAM, which is also a big advantage. Details are described in the ChangeLog: http://www.ucapps.de/midibox_sid_changelog.html And the release package can be downloaded from http://www.ucapps.de/mios_download.html Note: the PIC18F4685 is a very new microcontroller, it's hard to find it in local or mailorder shops. But since it provides so important features for MBSID V2 (CAN and bugfree EUSART), this shouldn't prevent me from using it for the upcoming project SmashTV will do batch orders directly from Microchip in future and sell the chips in his webshop for an extremely fair price: $9.95 per piece And the other good news: doc is doing the distribution for Europe, he offers the chip for EUR 7.90 per piece (+ shipping costs) - just contact him via PM, 30 pieces are already available! :) The chips are preprogrammed with bootloader and MIOS Best Regards, Thorsten.

Hi Whomper, I combined all your postings, because this simplifies the answering. Now I only need to write a single posting, in which I can refer to a new release candidate! I found a way to reproduce the pattern switching issue in song mode - I just used the record function of Logic, which sends a new song position, and then starts to record all incoming MIDI events. The root cause was found out very quickly, and it should work now (please try it out) Multiple Song BankSticks: I checked this, but there is too much code which would have to be changed. Wouldn't it be better for your workflow, if you would be able to switch patterns directly from Logic? For example via CC? This would allow you to embedd the chains of patterns directly into a Logic Song. Copy issue: fixed Paste issue: the current behaviour was a special request by dcer10 (see MBSEQ V3 talk thread, where errors where reported and commented in the past). I prefer the current implementation, and a variation which would allow to switch back to the old behaviour would be too complicated, therefore I would say: so long everybody knows that all track parameters are copied, it should be manageable, and it is only a documentation issue. I wasn't able to reproduce the "pattern delete" issue. There is no function available which is able to clear any song position, there is especially no function which would clear multiple positions (from start position till song end) Could it be that you switched to an empty song by accident? If not: could you please give me some step-by-step instructions how to reproduce this? Here the new release candidate: http://www.ucapps.de/tmp/midibox_seq_v3_1_rc1.zip I changed the version number from 3.0 to 3.1, since a 64k Song BankStick is supported now. The random generator has been enhanced as well, it now allows to specifiy individual "intensities" for all parameter and trigger layers Please note: the CHANGELOG.txt describes a way, how to initialize the upper half of the 64k bankstick without loosing the previous content of the lower 32k half. Best Regards, Thorsten.

Thank you, Lyle! Thats a great and especially very good documented project! :) I will be propably one of the first users, as I already own the chips, mounted on a PCB and ready for use (@doc: thanks again! :)) - I'm planning to use MBMixer to mix the audio outputs of my MIDIbox SID, MIDIbox FM and the 4 CEM3378 filters with total recall capabilities. The project is now also listed in the navigation bar of ucapps.de Best Regards, Thorsten.

Mike burned another PIC18F4620 and sent me the .hex file - it is complete. He will take special care on the next deliveries (second verify), so that this (hopefully) doesn't happen again. The reason for the failure is still unknown, but it wasn't Mike's fault. Best Regards, Thorsten.

Thank you very much for the compliments! :) Please note, that a new version is available in the MIOS download section (midibox_seq_v3_0a_rc3) which contains some bugfixes for song mode (x16 action was missing, incoming MIDI clock song pointer was not handled properly). Whomper reported another issue, which I wasn't able to reproduce yet, but I will test this intensively after my vacation - so, another update can be expected in ca. 2 weeks. The new x16 action requires a small change in existing songs, therefore an update to v3_0a_rc3 is strongly recommented. Best Regards, Thorsten.

Thanks for testing! I wasn't able to reproduce this yet, but I will try this again with different sequencers after my holiday. So, a new release candidate can be expected in ca. 2 weeks Best Regards, Thorsten.

That's all, you've been warned! Best Regards, Thorsten.

Ich bezweifle, dass es am Bootloader liegt. Markus' Problem ist zwar ungeklaert, aber der Loader kommt bereits in vielen MIDIboxen zum Einsatz. Die MIDI Troubleshooting Guide befindet sich hier: http://www.ucapps.de/howto_debug_midi.html Gruss, Thorsten.

This should also work now (step position counter was divided by 4 on incoming song position messages from Logic) -> http://www.ucapps.de/tmp/midibox_seq_v3_0a_rc3.zip Best Regards, Thorsten.

While reviewing the code, I noticed that the song position parser can be realized on a much more robust way by moving it into the NotifyRx handler of MIOS (which will be triggered immediately on received events) For a quick test, I scrubbed over the arrange window of Logic at various BPM rates, and the sequencer always got in sync with Logic again - so I think that it's working stable now :) The release candidate can be downloaded from this location: http://www.ucapps.de/tmp/midibox_seq_v3_0a_rc1.zip Please note: I also added the "x16 loop action", which means, that songs have to be overworked. "jump pos" is shifted to x16 "jump song" is shifted to "jump pos" "mixer map" is shifted to "jump song" So - songs have to be adapted if they are using these actions! Just increment the action by one Best Regards, Thorsten.

Ok, I think I found the location which needs to be improved. Could you please try the following: open seq_core.inc, search for "SEQ_CORE_Reset", and replace all lines between SEQ_CORE_Reset and SEQ_CORE_Reset_NotMaster by: SEQ_CORE_Reset ;; play off events of all tracks call SEQ_CORE_Hlp_PlayAllOffEvnts ;; init the reference counters SET_BSR SEQ_BASE setf SEQ_CLK_TICK_CTR, BANKED setf SEQ_CLK_STEP_CTR, BANKED BIFSET SEQ_CFG0, SEQ_CFG0_BPM_CLK_SLAVE, BANKED, rgoto SEQ_CORE_Reset_NotMaster SEQ_CORE_Reset_Master ;; clear all sequencer requests (i.E. a stop event!) clrf SEQ_REQ, BANKED ;; cancel all requested clocks (only relevant for master mode) clrf SEQ_CLK_REQ_CTR, BANKED movlw 3 movwf SEQ_SENT_CLK_CTR, BANKED SEQ_CORE_Reset_NotMaster [/code] For the slave the "clock counter reset" has to be done at a different place, so that it works in all cases. But for a first try this works ok It would be interesting if this works with your Logic version? (I'm using PC v5.5) Best Regards, Thorsten.

ok, got it! The whole synchronisation is not working properly anymore, seems that I messed up something during the "last quick changes" this week. I will check this and propably release a testing build today Best Regards, Thorsten.

Ich finde es immer wieder erstaunlich, wie sauber man so etwas aufbauen kann! Klasse! :) Wegen des PICs: PM Gruss, Thorsten.

Ok, I received the PIC today and noticed, that a small portion of the bootloader was not programmed into the PIC: :10024000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFBE :10025000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFAE :10026000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF9E :10027000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF8E [/code] Thats a 64 byte range between 0x240 and 0x27f. This explains the strange behaviour (upload request, but programming not possible) After reprogramming the PIC (I tried v1.2a and v1.2b) the chip works ok. I also tried the protection mechanisms - uploading a wrong MIOS Version (e.g. 1.8 ) does not overwrite this flash area, this is good! So far I know, the P18 software programs 64 byte blocks, so it could be that one block was missed. But it could also be, that Mike's .hex file was incomplete. Therfore: @Monokinetic - it would be very helpful to get your .hex file! Best Regards, Thorsten.

Hi Ole, in distance to MBSEQ V2, the "Voti/Alps" compatible encoder type "MIOS_ENC_MODE_DETENTED2" is now selected by default, as this fits with the hardware of most users. So, you have to edit the encoder settings at the bottom of setup_mbseq_v3.asm Btw.: I received your PIC today, I will answer in the appr. thread Best Regards, Thorsten.

This is clearly a bug and I will fix this soon. Did you (or anybody else) find other issues which are worth for being fixed in the first "service pack"? Best Regards, Thorsten.

Yes, I'm aware of this issue - the reason is, that for a proper synchronisation the internal song/step and clock divider counters have to be prepared for the next step, so that the correct step is played with the next incoming MIDI clock. Since Logic can send more song positions in addition (e.g. while scrubbing the song position pointer over the arranger window), I found it more useful to prepare, but not to execute the next step, just to save some CPU time and to prevent unnecessary delays (in worst case, a MIDI In buffer overflow could happen) Therefore the LCD and LEDs will show the scenario before the actual selected song position - just waiting for the first clock so that the engine will properly update all variables. Btw.: the receive handler for the song position pointer is not able to recalculate all parameters, especially the progression parameters and the clock dividers - this is too difficult, as there is no simple "formula" which allows to determine exactly such variables based on the song position. You will find a lot of inconsistencies here... :-/ Best Regards, Thorsten.

The slowest setting is required for some PICs because a 100 nF cap is connected between Vss and Vdd This cap is not part of the "Brenner5" schematic from sprut.de, on the other hand: without this cap it isn't possible to program newer PICs like the PIC18F4685 (-> MIDIbox SID V2) I informed Sprut about this imperfection, he has confirmed the difference but he hasn't improved the software (nor Brenner5) yet... So: by removing C7 you could achieve a better performance, but newer PICs cannot be programmed anymore. And to make the confusion perfect: with "WinPIC" (requires special configuration file for MBHP_BURNER) I noticed better results, but there are new - different - issues... so that I would say: good that we only need to program the bootloader, the rest can be uploaded via MIDI :) Best Regards, Thorsten.

This nice looking MIDIbox64 has been created by Alientom - it's propably the first MIDIbox made in Japan! :)

Hey, ich habe meine allerste MIDIbox (anno 1998) in ein Sat-Receiver-Gehaeuse eingebaut, und die Potis stammen aus einer defekten Orgel. Den PIC (sowie das dazugehoerige Programmiergeraet) hatte ich bei einem Programmierwettbewerb gewonnen, und den externen ADC (der damals noch notwendig war) erhielt ich als kostenloses Sample. Im Grunde musste ich fuer meine MIDIbox nur die rote Klebefolie aus dem Baumarkt bezahlen - Beschriftung: der wasserfeste Edding war zu der Zeit noch nicht ausgetrocknet ;-) Zu den Fadern und Potis: ueberpruefe mal, ob die auch eine lineare Spannung ausgeben. In einem Audio-Mixer sind normalerweise logarithmische Fader eingebaut, und die sind ungeeignet. Gruss, Thorsten.

Why not uploading MIDIO128 as proposed in the Wiki? (-> http://www.midibox.org/dokuwiki/doku.php?id=din_module) It's easier for debugging Best Regards, Thorsten.

So far I remember - but I could be wrong - the feedback path between Data In->Data Out is used to detect the burner. This means: if the voltage level of the data pin is changed between 0V and 5V, but "data out" (see schematic!) doesn't toggle, the burner won't be detected Best Regards, Thorsten.

The voltages are ok. I think that you are just mixing "DO" (for Data-Out) with "D0" (for Dataline Zero) On the DINX4 board, the D0 line is an input, which is pulled up via 10k to +5V. So, the measured voltage level is as expected, and the module interconnections are ok. Best Regards, Thorsten.

thanks for the input! The warning level of the "positive version" is too low - it's like if you are saying "smoking can cause heart disease" - some people will smoke anyhow. So, I've changed the sentence to: Never plug a PIC into the socket if you haven't done the initial hardware checks. Also, do not plug in a PIC if the RED or YELLOW LED lits up, because the PIC could be destroyed if the pins are getting in touch with an active Vdd/Vpp level before the Vss pins are connected to ground! Could somebody please translate this to proper english? (I don't mean this sarcastically, I'm happy when somebody informs me about unclear or wrong sentences on my website) Best Regards, Thorsten.

Yes, please! This allows me to compare the contents between both failing PICs - great that you thought about this! :) Best Regards, Thorsten.