TK.

alright, I will add this to the TODO list. AC already did most of the work, and as experienced with his speakjet project the migration of his code should be easy. :) Best Regards, Thorsten.

I could hack an example for a table based method which is easy to modify. For first time right: could you please post the required MIDI note values in following format: 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, // row1 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, // row2 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, // row3 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f, // row4 0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, // row5 0x28, 0x29, 0x2a, 0x2b, 0x2c, 0x2d, 0x2e, 0x2f, // row6 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, // row7 0x38, 0x39, 0x3a, 0x3b, 0x3c, 0x3d, 0x3e, 0x3f, // row8 [/code] You could use decimal number instead of hexadecimal as well if this is easier to read for you. Best Regards, Thorsten.

The only guy who tested the code so far on a MBSEQ V4 (without L) is Hawkeye - I haven't built the hardware by myself... However, but I think that the issue is related to the SEQ_LED_PinSet function, which doesn't pass values to MIOS32_DOUT_* functions, but to the BLM_CHEAPO_DOUT driver instead. s32 SEQ_LED_PinSet(u32 pin, u32 value) { #ifdef MBSEQV4L if( pin < 64 ) return BLM_CHEAPO_DOUT_PinSet(pin, value); if( pin >= 128 && pin < 196 ) return BLM_X_LEDSet(pin-128, 0, value); #else if( pin < 128 ) return MIOS32_DOUT_PinSet(pin, value); if( pin < 196 ) return BLM_X_LEDSet(pin-128, 0, value); #endif return -1; // pin not available } [/code] I just have changed the BPM digit driver, so that it directly accesses MIOS32_DOUT Could you please check if this temporary version works: http://www.ucapps.de/mios32/midibox_seq_v4l_055b.zip Best Regards, Thorsten.

It would be interesting for me if the transmit buffer is really cleared - I'm not an AVR user, but sometimes design flaws of other microcontrollers are interesting to know. ;) I'm setting the DMA_IT_TC flag on the RX channel, not TX channel, therefore I would expect that the interrupt is triggered when the last data value has been read. But I will doublecheck this sooner or later (low prio) Best Regards, Thorsten.

I also thought about this alternative solution - it should work, but you need to learn a bit more about the STM32 internals since I can't give you an example for this. I wasn't sure if you already considered this, and therefore thought it would be better to give you a "low hanging fruit" proposal first! ;) You won't need a DMA in this case, just configure the STM32 SPI as a slave and handle incoming bytes from an ISR. The app. handler for MIOS32 SPI port 0 (== STM32 SPI port 1) is: void SPI1_IRQHandler(void); It's declared as "weak" in startup_stm32f10x_hd.c - means: just insert it into your app.c file to overload the function. When AVR receives the dummy byte, the ISR can put the next value into the transmit value. STM32 will get an invalid value which is not correct because of the timing constraints. But on the next SPI transfer the byte will be correct, because AVR had enough time to write the new value into the transmit buffer. In other words: by duplicating the SPI transfers it's ensured that the correct value will be transmitted with each second byte Best Regards, Thorsten.

Yes, for all demos I used the Kraftzwerg VCO. In the first two demos I used the Kraftzwerg filter, and in the last two demos SSM2044 filters. VCOs and VCFs are directly controlled by MBCV, this basically makes the synth :) (the two analog LFOs and ENVs of Kraftzwerg are not used) Best Regards, Thorsten.

such tricks could lead to unstable transfers if you can't guarantee that the AVR doesn't read the dummy bit. But I've maybe a better idea - more about this at the end of this posting. The timer already initiates SPI transfers before it has been configured (race condition). Funny, seems to be a bug in the STM32 port of MIOS32_SPI - I will check this later. Probably I never noticed this since the callback method is currently only used by MIOS32_SRIO - and here it doesn't really matter if DIN SR values will be read of the last or previous scan. Ok, now to the idea: data reduction and double byte transfers: Data reduction: I guess that you want to scan the ADC channels with 12bit resolution since the sensor signals are not linear. But: you could already linearize the conversion result through a lookup-table to a 8bit value. The required table size would be 2^12 = 4kb, and I guess that your AVR has enough free memory... Double byte transfers: you could insert dummy bytes into the datastream which are only used to trigger the ISR, and to prepare the actual data transfer. This has the advantage, that SPI transfers could be done at a much higher clock rate than the method we tried before (extremely reduced data rate to ensure that the byte is written into the Tx buffer before the next transfer is started) Rough calculation: assumed you would only send 8 byte values instead of 12bit values, and assumed that the stream is filled with dummy bytes, you would have to send 2*96 = 192 bytes. But you will be able to transfer it at a much higher bitrate, let's say MIOS32_SPI_PRESCALER_8 (111.1 nS) This means that all bytes could be transfered within 170 uS! :) Best Regards, Thorsten.

Btw.: the frequency was wrong... I wanted to write 0.8 kHz, not 1.2 kHz ;)

Thanks for the compliments! :) I haven't read your older posting (again), therefore I didn't remember the constraints. On the other hand, it could make sense to consider changes which allow block transfers, because currently you are facing the advantages... 144 bytes have to be transmitted within 1 mS, accordingly the max. allowed bitrate is 868 uS. Unfortunately the next matching STM32 SPI prescaler is "MIOS32_SPI_PRESCALER_64" (-> 888.9 uS), which is a bit too much for 1 mS (144 bytes would be transfered within 1.023 mS). It would be very tricky to synchronize this properly. But: as a counter measure, you could decrease the FreeRTOS realtime clock frequency from 1 kHz to 0.8 kHz (to give some additional headroom for the SW handling). This can be done in programming_models/traditional/FreeRTOSConfig.h -> configTICK_RATE_HZ (change from 1000 to 800) If this helps, I will make this constant configurable in mios32_config.h, so that later you wouldn't need to change this global configuration file. Best Regards, Thorsten.

It isn't efficient to transfer the data bytewise, this keeps the CPU too busy. I would recommend to use a DMA based block transfer. Instead of: int i; for (i=0; i<144; i++) { Data[counter] = MIOS32_SPI_TransferByte(0, 0b10010110); counter++; MIOS32_DELAY_Wait_uS(1); } [/code] write: [code] // - shiftOutData should be an array which contains 144 x 0x96 (the TransferBlock function doesn't allow to define a default value) // - received values will be written into Data array // - MyDmaCallback specifies a function which will be called after the DMA transfer has been finished. MIOS32_SPI_TransferBlock(shiftOutData, Data, 144, MyDmaCallback); This isn't a time consuming function, the DMA will just be configured for autonomous transfer, and then the function exits immediately. You could call it from APP_SRIO_ServicePrepare() for example - it's called each mS with high priority! Once all bytes have been transfered, the callback function will be executed from a DMA interrupt handler. The callback should by short as well (since it's a high-prio function). But I think that it's ok when you are doing the re-ordering stuff in there. The received values should be processed from a FreeRTOS task, priority 3 should be fine. /Edit: IMPORTANT: in order to avoid the data access conflict that you had before, it's still important that you copy the received data into a second array (you name it "Values") while re-ordering Data! It makes also sense to determine and to notify changed values, an example can be found in the MIOS32_SRIO_DMA_Callback function here: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fmios32%2Fcommon%2Fmios32_srio.c The MIOS32_DIN_SRChangedGetAndClear function shows you how to take over the notification from a task, see http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fmios32%2Fcommon%2Fmios32_din.c Best Regards, Thorsten.

implemented: the LFO phase can be configured from 0..255. It's not only useful for chorus effects, but also results into nice sequences when dynamically changed while (for example) a bassline is playing. implemented (0..127) My favorite usecase is to apply XOR between a source (e.g. LFO) and a constant value :) I've to think about this... an expression evaluator is definitely not practical. Currently three sources can be combined by using two MODs. The second MOD can take over the modulation result of the first MOD. good idea! In addition: if the MBCV gets an optional "tb303-like" interface with a one octave input, it could be used to enter the scale as well. I got the point and your proposal makes sense. There is no need to re-use exactly the same table like MBSEQ. you are right! Thanks for the input! :) Ok, here an update: I had some SSM2044 stereo filter fun: In following demo a LFO is routed thru the modulation matrix to the CV channels which control the cutoff frequency. One channel is inverted, and this is the result: http://www.ucapps.de/mp3/midibox_cv/mbcv_mod_demo1.mp3 In the second demo I combined ENV (with exponential curve!) and LFO through the MOD matrix to produce different stereo effects while a simple bassline is playing: http://www.ucapps.de/mp3/midibox_cv/mbcv_mod_demo2.mp3 Listening with headphones is recommended! ;) Best Regards, Thorsten.

Important question: is there a ground connection between the boards? In this schematic: http://www.ucapps.de/midibox_sid/mbsid_v2_communication.pdf you will find it at J11:Vs Best Regards, Thorsten.

I looked into the datasheet: http://www.reichelt.de/index.html?;ACTION=7;LA=3;OPEN=0;INDEX=0;FILENAME=C200%252Ftaster.pdf;SID=11TVLbZ38AAAIAAG9MIgIec1e46ae3eb4fc2fe4e011f269170227 Indeed, the footprint doesn't match exactly with the PCB. Instead of 0.3/0.2 it has 0.256/0.177 (resp. 6.5 / 4.5 mm -> seems that this button is optimized for metric measure system) I don't find this so dramatic, but for the perfectionists it would be interesting to know if there are buttons with 0.3/0.2 footprint? Best Regards, Thorsten.

The footprints are identical, we used the default switch of the KiCad library. It matches with the typical 0.01 inch grid measures, and since I'm normally using veroboards for frontpanels, I'm used to squeeze the pins. ;) Does anybody know if there is an optimized version for these switches? Best Regards, Thorsten.

Yes, this is a good & inexpensive replacement. Let us know replacing the LCD helped. Best Regards, Thorsten.

Ca. two years ago, where I tried to combine MIDI+COM, it worked under MacOS, but caused a blue screen under Windows. Meanwhile this combination is not working under MacOS anymore, I'm not sure why but haven't spent much debugging effort for this topic since this is a very exotic usecase anyhow. I don't think that a MIDI+MSD combination will work in parallel, especially because it seems that Windows can only assign a single driver to a USB port. Best Regards, Thorsten.

This issue has been fixed in MIDIO128 V3.005 I also noticed that one of your MIDI files caused a bad timing behavior of the sequencer and found + solved the reason for this as well (unnecessary SD Card accesses). -> all your MIDI files are played with stable timings now :) Best Regards, Thorsten.

Thanks for the nice idea! Of course, I could integrate the "force-to-scale" functions of MBSEQ into the modulation matrix as an additional "operator". This would not only allow to quantize/harmonize analog inputs, but any modulation source (such as LFOs). I do agree - and I would also add the protection diodes to ground against negative voltages, otherwise the analog input could be fried if it is supplied by a bidirectional control voltage. Best Regards, Thorsten.

Btw: The CV Channel setup is completely implemented: And the modulation matrix is working: You will notice that in difference to MBSID it's possible to take a modulation source of another CV channel -> keyword "cross-modulation"! :) I also prepared 8 "knob" functions, because I think that it will be better to use configurable knobs for the "physical control surface" instead of dedicated knobs for each modulation source. Next step is to implement an internally handled copy/paste/clear function. Thereafter I will create a new stereo demo with Seppoman's SSM Filters :) Best Regards, Thorsten.

Update: the envelope generators got a Fast and Oneshot option. I also added an Offset parameter to ENV2: This results into an alternative usecase: ENV2 can be used as a configurable LFO - just "draw" a waveform and listen to the result! By syncing ENV2 to MIDI clock, you can even "draw your rhythms" :) Here two audio examples - I used extreme settings to demonstrate the difference, please don't expect nice sounds :ahappy: Filter modulated via ENV2: http://www.ucapps.de/mp3/midibox_cv/mbcv_env2_demo1.mp3 0:00 slow modulation 0:07 added a spike 0:11 and another spike 0:21 disabled curve 0:27 enabled curve again 0:35 now a bit faster 0:40 and even faster 0:48 much faster! (sounds like my good old 4800 baud modem!) 1:07 drawing different curves 1:28 back to slow mode 1:33 changing the delays between individual steps 1:52 finally a nice rhythm ;) Pitch modulated via ENV2: http://www.ucapps.de/mp3/midibox_cv/mbcv_env2_demo2.mp3 0:00 slow modulation 0:04 adding some spikes 0:12 disabled curve 0:16 enabling curve again 0:28 changing the delay for some steps 0:38 and some levels 1:15 now a bit faster 1:50 etc... 2:04 btw.: this FM effect is realized by setting different steps to min/max level 2:24 random touches... /edit: next demos with stereo SSM2044 here: Best Regards, Thorsten.

:flowers: The J15_S jumper has to be mounted (-> select the 5V option) Seems that I really have to improve the documentation for this topic! Best Regards, Thorsten.

Got them, will check tomorrow! :) Best Regards, Thorsten.

MBSID allows to directly change any parameter via SysEx without loading and writing back the (huge!) patch buffer. See the SysEx documentation: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_sid_v2%2Fdoc%2Fmbsidv2_sysex_implementation.txt 06/a) F0 00 00 7E 4B <device-number> 06 <WOPT> <AH> <AL> <value_l> <value_h> F7 Direct Write of parameter into patch buffer (<AH> = 0..3, <AL> = 0..7F) Patch address: (<AH> << 7) | <AL> <WOPT>: options to speed up communication with editor, behaviour depends on engine See topic "Direct Write Options" at the end of this document [/code] Arp parameters: [code] 0x06c | Arp Mode | [0] 0=Arp disabled, 1=Arp enabled | [3:1] Direction: 0=up, 1=down, 2=Up&Down, 3=Down&Up, 4=Up&Down 2, 5=Down&Up 2, 6=random | [4] Sorted | [5] Hold | [6] Sync with keys | [7] CAC (Constant Arp Cycle) 0x06d | Arp Speed Divider | [5:0] Clock Divider (0..63) (derived from global clock) | [6] Easy Chord | [7] Oneshot 0x06e | Arp Gatelength and Range | [4:0] Gatelength (0..31) | [7:5] Octave range (0..7 = 1..8 octaves) By using the WOPT feature it's possible to update the arp parameter of all oscillators and SIDs with a single SysEx command. (see end of the document for a more detailed description) Rutger's MBSID Editor uses the direct access as well, therefore parameters are quickly updated. This also means, that the most simple way to find out the SysEx string that you need to send is to monitor the output of the MBSID Editor when you are changing a parameter. Best Regards, Thorsten.

Could you please send me some of your MIDI files? Best Regards, Thorsten.

I still have no explanation why the hex upload doesn't work when the LCD is attached - this is very strange and needs some further analysis. A reason for the not working CAN access could be related to the DeviceID. Each core needs a unique ID, the change_id application helps to set it - was this obvious as well? If yes: are you able to create some pictures of your setup for additional inspirations? Then just attach them to this thread. Best Regards, Thorsten.