TK.

Hi Mike, interesting! You and me seem to be the only guys who are using this feature (it's one of my most favourite ones). According to the svn log, it wasn't working since 298 days, 21 hours, 10 minutes (it was working in v4 of course ;)) Fixed in v3.4e Best Regards, Thorsten.

Ok, I will add CC ramps to the song sequencer as well. CC ramps and LFO effects are planned as "global effects" as well, so I think that this should be combined (change the global configuration from a song) I also think that it makes sense to increase the number of song steps from 128 to 256 to get enough place for the new features. I restructured the BPM configuration page so that it can be used more intuitively: The "internal clock divider" has been removed, as the possibility to select a tempo preset has the same effect. The "external clock divider" has been replaced by the possibility to enter the PPQN rate at which the DIN Sync clock pin should be triggered (1..384 PPQN) The "External Restart" (which can be selected with MENU+METRONOME in V3) can now be triggered from the BPM page, so that no double assignment of the METRONOME button is required. The function can be optionally assigned to a dedicated button of course. It can also replace the METRONOME button function. Also new: the MIDI Clock Input/Output port setup can be done in the BPM page instead of the MIDI page. Best Regards, Thorsten.

There is an update (v3_4d): o In Slave Mode the sequencer won't switch to Master mode when the Play button is pushed. This automatic switching is only available in Auto Mode anymore[/code] Best Regards, Thorsten.

Hi, 48ppqn means that the clock has to be sent with double frequency. With some changes in the code it should be possible to realize this (the timer rate has to be doubled, the MIDI Out clocks need a predivider) - but it's nothing what I could write down w/o testing. I guess that it needs some tweaking until it will run perfectly! Unfortunately I don't own a LM-2 ;) Best Regards, Thorsten.

From your descriptions I assume that either the MIDI Out or windows driver of your MIDI Interface, or the MIDI In of the core module isn't working, because MIOS Studio tries to contact the core but doesn't get a response. The MIDI Out of the core module, and the MIDI In of your MIDI interface seem to be ok. Please do following tests of the MIDI Troubleshooting guide, and write down the results: TEST IN1: TEST IN2: TEST IN3: TEST IN4: TEST IN5: TEST IN6: TEST IN7: TEST INOUT1: Best Regards, Thorsten.

I used a MIDIsport 2x2 many years w/o issues. But the driver is multi client capable. If M-Audio Uno doesn't support multiple clients, this indicates that a different driver is used which could have bugs. Best Rgards, Thorsten.

Yes! Programs like Ableton Live allow to compensate Audio into the negative or positive direction in relation to the incoming MIDI clock to overcome such issues. Best Regards, Thorsten.

You have to differ between how much current can a 74HC595 source/sink w/o the risk for damage, and how much current can a single 74HC595 output source/sink w/o influencing the current through other outputs (resp. w/o violating the logic-level specs, but this isn't for interest here anyhow). On my original 4x16 Duo-LED Matrix design, there is a noticable influence once more than 8 LEDs are sinked through a single 74HC595 at the same time. Therefore I recommented sink drivers. Comment to answer from ST: they are right - if you are searching for a perfect solution, use a chip which has been created for driving LEDs. Comment to answer from Fairchild: they are right - they are speaking about a current limit through a single pin, they don't mention the influence between outputs, but you haven't asked for this... Comment to answer from ON: they are right, but Voh/Vol isn't for interest while driving LEDs (in other words: miss-using a logic chip) Best Regards, Thorsten.

True words! ;) Currently I would say, that connecting a MBHP_CORE_STM32 module to a MB-6582 via CAN will give us the most powerful options, since PICs can be used to access the SIDs while STM32 is doing the sound engine, communication and user interface work. If more than two SIDs would be connected to a single STM32 w/o the usage of additional microcontrollers, the firmware would mainly be busy to transfer data to the SIDs and wouldn't have so much time to calculate modulation sources and pathes - the problem: write accesses to SIDs have to be synchronized to the 1 MHz clock, this costs 2..3 SID cycles. While for a PIC this means the loss of 20..30 instructions, for a STM32 this means a loss of ca. 200 instructions per write access! Another advantage of using PICs: STM32 could send some "background jobs" to the PICs which are handled in parallel. E.g., FM modulation or playing samples. They could be handled with incredible high speed (e.g. 20 kHz - note: a C64 usually accessed the SID with 50 Hz) without loading the "master processor". There are two options I'm planning to evaluate in the next months before starting to program the firmware. 1) (over)clocking the SIDs with 2, 4 or 8 MHz! This would result into faster transfers. Disadvantage: lower frequencies cannot be played accurately anymore, and VCA envelopes are faster (*). Advantages: this could allow to handle 8 SIDs from a single STM32 w/o such a high performance loss. This could also allow to apply the ADSR workaround much faster, which means, that such an option could lead to the world-first "real SID" synthesizer with perfectly working ADSRs ;) Note that this option would work with PICs as well, which means that re-using the PICs from an existing MB-6582 is again the most powerful solution, everything else is only a cost-saving measure. /edit: (*) can also be seen as an advantage! 2) STM32 introduced a new connectivity line with derivatives which contain USB, two (!) CANs and an ethernet controller (unfortunately w/o PHY layer) beside of other useful peripherals. Two CANs means even higher bandwidth, USB can be used in parallel, and integrated ethernet controller is the cherry at the top (MIOS32_OSC is already up&running, in addition it would be possible to download new patches directly from the internet ;)) These chips are not available yet, but it will be possible to prepare the firmware for such an upgrade option, which could be used for the final design. Best Regards, Thorsten.

Problem: the SONG button already has a second function, it switches between Song and Phrase mode. Another problem: if somebody presses SONG and MUTE (or SONG and PATTERN) unintentionally together, the current song position would be overwritten. I think, that it would be better to have a "store current" function assigned to a GP button, so that no (hidden) button combination is required. So: select a pattern action, press "store current" and the current pattern set will be copied into the song step Or select a mute action, press "store current" and the current mutes will be copied into the song step. Same for mixer map and tempo, and maybe for future actions as well. Mutes cannot be stored together with pattern sets in a single step, since actions share the same memory locations (8 bytes of a song step can either store pattern/bank changes, or a jump, or a song change, or a mixer map, or a tempo change or a mute pattern and maybe more in future). In addition, it wouldn't be so easy to display a complete song step (pattern set and the mute pattern) on a single LCD anymore. I would have to remove the info screen of the second LCD... So - storing a Mute pattern in a separate song step has many advantages, and I won't search for a different solution. Best Regards, Thorsten.

Yes - note that tempo changes with ramp value "0 s" will be done immediately. So, you can store your prefered tempos there. And you can add "tempo sweeps" if desired. When you listen to the demo, you will notice that I did pattern changes during tempo sweeps. They are handled in background. It's even possible to interrupt an ongoing sweep by a new preset, which gives you the possibility to play a bit with different up/down ramps (some kind of "scratching" ;)) The advantage of my solution is, that prefered tempo changes can be prepared - thats really important for live sessions (no need to search for the right tempo with the encoder) If you prefer a single-button solution for a tempo change/sweep *together with* a pattern change, the song phrase enhancement will be the solution. Best Regards, Thorsten.

They could (these are floats), but you wouldn't really notice an effect - such ramps sound more like a sequencer hick-up. Currently it enters the preset screen for the case that it isn't assigned to a Fx button. Currently you just only need to press different preset buttons to achieve similar effects. I think that they are more useful than your proposal - you will see this once playing with the function. Best Regards, Thorsten.

So, you mean something like this: Selectable in such a page: Which sounds like this: http://www.ucapps.de/mp3/midibox_seq/mbseqv4_demo_tempo_sweeps.mp3 Good that I considered automated tempo changes from the beginning while implementing the MIDI event scheduler :) Note that tempo changes with a definable ramp time could be part of a song phrase as well (definable in song page, similar to Pattern Sets, Mutes, Mixer Maps, etc...) Best Regards, Thorsten.

Link to the new thread http://www.midibox.org/forum/index.php/topic,13485.0.html

It cannot be changed, as sm_fast scans the keyboard "so fast as possible" in an endless loop. If you prefer a defined scan period, use sm_slow. On the other hand - why do you want to change the speed? No, the timer is only used to decrement the debounce counters. sm_slow uses the common MIOS hooks to scan a matrix and can be used in parallel to other routines w/o drawbacks. E.g., I'm using the same approach for MBSEQ, MBSID, MBFM - and these are really CPU intensive applications. sm_fast is a hack which controls the SRIO chain directly so fast as possible. This should be done exclusively. No other routines should run in parallel. Best Regards, Thorsten.

How about following solution: a special GP button function in SONG page which copies the current pattern set and mutes into a "phrase slot" of a song. This would allow us to quickly store and restore a complete scene (so - not only the mutes) into up to 16 phrases per song, and it would allow to visualize & edit the scenes later (e.g. to remove pattern changes if they are not wanted). As a side effect, this would also allow to chain the phrases to a complete song (if desired)... some kind of interactive song step recording. Best Regards, Thorsten.

Better idea: Similar to Actions like Jump Position/Song/Select Mixer map, a "Mute" Action could be provided which allows you to enter a mute pattern into a song step. E.g.: [tt] Pos A1 Mute oooo **** **** **** Pos A2 x2 1:A1 2:A1 3:A1 4:A1 Pos A3 x2 1:A2 2:A1 3:A1 4:A1 Pos A4 Mute oooo oooo **** oooo Pos A5 x4 1:A2 2:A2 3:A1 4:A1 Pos A6 x4 1:A2 2:A2 3:A1 4:A2 Pos A7 Jump A5 [/tt] Remember that each song is splitted into 16 phrases, so that you can define up to 16 mute scenes this way. E.g. - if you don't use pattern selection at all. [tt] Pos A1 Mute oooo **** **** **** Pos A2 Stop Pos B1 Mute oooo oooo **** **** Pos B2 Stop Pos C1 Mute oooo oooo oooo **** Pos C2 Stop [/tt] etc. Best Regards, Thorsten.

such an handling isn't practicable while playing live, as you don't have direct access and a sufficient visual feedback while selecting a mute scene (where did you store a certain scene, how many times do you need to push the Fwd/Rew button) In addition, I think that especially in song mode, Fwd/Rwd should be used for the intended purpose, and not assigned to multiple functions depending on a menu page. So, you think that even after one month you still remember, which pattern you assigned to Mute scene #13 for Song #41, and Mute Scene #4 for Song #12 while playing live? I don't think so... This would be my personal preference as well, since this is the intention of phrase mode. Providing different use models only leads to unnecessary confusion (and too much effort at my side - consider, that after each change I've to ensure, that all options are still working - even features I would never use by myself!) (deleted as misunderstood, since I already got a better idea) Best Regards, Thorsten.

Following lines: movlw 0x90 ; check for Note On at channel #1 cpfseq MIOS_PARAMETER1, ACCESS rgoto USER_MPROC_NRE_NoNoteChn1 [/code] have to be replaced by: [code] movf MIOS_PARAMETER1, W ; get status byte andlw 0xf0 ; mask out MIDI channel xorlw 0x90 ; check for Note On bnz USER_MPROC_NRE_NoNoteChn1 ; skip if not a Note On event (ignore wrong label name) Replace: USER_SR_Service_Finish clrf MIOS_PARAMETER1 movlw 0x00 call MIOS_DOUT_SRSet movlw 0x01 call MIOS_DOUT_SRSet movlw 0x02 call MIOS_DOUT_SRSet movlw 0x03 call MIOS_DOUT_SRSet [/code] by: [code] USER_SR_Service_Finish movlw 0x00 call MIOS_DOUT_SRGet movlw 0x00 ; (*1) andwf MIOS_PARAMETER1, F movlw 0x00 call MIOS_DOUT_SRSet movlw 0x01 call MIOS_DOUT_SRGet movlw 0x00 ; (*2) andwf MIOS_PARAMETER1, F movlw 0x01 call MIOS_DOUT_SRSet movlw 0x02 call MIOS_DOUT_SRGet movlw 0x00 ; (*3) andwf MIOS_PARAMETER1, F movlw 0x02 call MIOS_DOUT_SRSet movlw 0x03 call MIOS_DOUT_SRGet movlw 0x00 ; (*4) andwf MIOS_PARAMETER1, F movlw 0x03 call MIOS_DOUT_SRSet movlw 0x04 call MIOS_DOUT_SRGet movlw 0x00 ; (*5) andwf MIOS_PARAMETER1, F movlw 0x04 call MIOS_DOUT_SRSet (*1) .. (*5): instead of 0x00, you have to set an AND mask which matches with your requirements. E.g., if the rightmost DOUT of the second SR shouldn't be cleared after 1 mS, use "movlw 0x01" instead of "movlw 0x00" if two rightmost DOUT of the second SR shouldn't be cleared after 1 mS, use "movlw 0x03" instead of "movlw 0x00" if only the leftmost DOUT of the second SR shouldn't be cleared after 1 mS, use "movlw 0x80" instead of "movlw 0x00" etc. Best Regards, Thorsten.

The EXIT button exits the page and it exits the menu. ;) You could also call it MENU if you want. Best Regards, Thorsten.

Hi, could you please try this updated release: http://www.ucapps.de/mios/midimon_v2_0c.zip I noticed that v2_0b contained an expired J5_IO driver, which got some changes meanwhile. This could be the reason. Best Regards, Thorsten.

Best Regards, Thorsten.

Please wait until Twin-X restores some forum files from the backup. It's totally clear which features are missing (all modifications have been logged), and it isn't required that you start to list them here. I just don't want to spend time for something which can be solved in 1 minute by copying files from the backup. Best Regards, Thorsten.

If you are using MIDIbox64E, open mb64e_midi.inc, search for MB64E_MIDI_SendEncEvent_M3 , and replace the code by: MB64E_MIDI_SendEncEvent_M3 ; == ENC_MODE_40_1 --- modified to send 0x40/0x41 movlw 0x41 btfsc MIDI_EVNT_VALUE, 6 movlw 0x40 movwf MIDI_EVNT_VALUE rgoto MB64E_MIDI_SendEncEvent_Send [/code] Best Regards, Thorsten.

It should work with 11 instead of 02 See also mios_backup.txt o if additional BankSticks are connected, do the same like above, but change the BankStick ID (1-7) like shown here: +--- BankStick ID | F0 00 00 7E 40 00 01 40 00 20 00 F7 F0 00 00 7E 40 00 11 40 00 20 00 F7 F0 00 00 7E 40 00 21 40 00 20 00 F7 F0 00 00 7E 40 00 31 40 00 20 00 F7 F0 00 00 7E 40 00 41 40 00 20 00 F7 F0 00 00 7E 40 00 51 40 00 20 00 F7 F0 00 00 7E 40 00 61 40 00 20 00 F7 F0 00 00 7E 40 00 71 40 00 20 00 F7 For 64k BankSticks use: F0 00 00 7E 40 00 01 40 00 40 00 F7 F0 00 00 7E 40 00 11 40 00 40 00 F7 F0 00 00 7E 40 00 21 40 00 40 00 F7 F0 00 00 7E 40 00 31 40 00 40 00 F7 F0 00 00 7E 40 00 41 40 00 40 00 F7 F0 00 00 7E 40 00 51 40 00 40 00 F7 F0 00 00 7E 40 00 61 40 00 40 00 F7 F0 00 00 7E 40 00 71 40 00 40 00 F7 [/code] Time to change your avatar (Homer Simpson? ;)) Best Regards, Thorsten.