monokinetic

My boards showed up today as well, thanks! Now for some soldering :)

2 pairs for me please. Thanks for offering!

And a couple more sent from Praha. Merry Christmas TK :)

TK, partly as a ping to ask if you have any ideas about the above, but also I would like to ask if there is any kind of SRIO interconnection test for MIOS32? I tried a DOUT over the weekend with my STM32F4 board to get around the above gates issue and I can not get any DOUT pins to trigger using MBCV2.... not sure if it's my hardware and not sure how to test further!

Hi all, I've been using MB CV 2 over the summer and it really is great! I have it running on an STM32F4 CORE and one of the original design AOUTs. Currently I would like to use the 2 gates from the AOUT board to trigger different things in my modular, and I can generate a gate no problem by sending a MIDI note on channel 1. The problem is that I want to use the separate gates on 2 different MIDI channels and I can't get it to work. Using the Lemur interface, I set the 1st CV channel to receive on MIDI Channel 1 and the 2nd CV channel to receive on MIDI channel 2. Then I send MIDI notes on both of these channels from my DAW, but both gates only work when I'm sending notes on MIDI channel 1. Should this work? Also in relation to this, I think a good addition to the interface would be a way to assign a couple of gates / DOUTs per CV channel from the user interface. This could be added to the Default page for example. Cheers David

I have read through the wiki page, excellent documentation. Thanks for sharing! And nice to meet you BOB ;) Count me in for one of the FPGA boards, and some BOBs as well.

Benoit, I'm watching this with great anticipation! Oh and BTW your product page still describes the RTP-MIDI OEM board as having "Up to 8 RTP-MIDI sessions in parallel". David

Hi Chriss, Thanks for posting your findings, that just makes me want to get this built into my seq even more! David

Wow this looks perfect, nice work gang! I would vote for a Ponoko type case, ala Sammich devices. If there's a gorup buy for this, I'm in. I'm sure most people who have the Encoder / LED boards would buy into this..... Maybe the top 3 elements (buttons, LCD, OLEDs) could be split into separate PCBs, then you can order your front panel depending on your preference i.e. left handed or right? Modular designs are always more felxible. In terms of height of the box, will this attempt to include the AOUT in the same box? I would suggest not. My plan is to put the AOUT behind a panel in my synth, and drive it with the core / front panel controls over a transistor buffer. That means the AOUT can be close to the dual power supply in the modular, and the control panel can be mounted close to the iPad away from all the modular's cables ;) What would be amazing would be to use this proposed surface as a generic surface to also edit my other devices, MBFM and MBSIDs, all from a central panel :D

Wow! I must add that MBCV2 is the most fun thing I have built, since the sequencer :D I will have to play with it some more to be able to imagine a physical interface. The Lemur usability is really good already IMO. Maybe something using those screens with encoders arranged around them, with the screens showing encoders values? TK: could you post the part number for those screens? I think I might have to add them to my panel after seeing the video! cheers.

Wow TK that was fast, you're unstoppable! I will not be able to test this for a while unfortunately as I am on the road without my Seq :( but will be back mid-January for some testing and promise to follow up with some feedback...

OK I was thinking the MBHP_AINSER8 module, but wouldn't want to sacrifice performance. Cool. I will either try it with MBCV2 on LPC and AINSER8, or would a PIC core also be suitable? Sure that would be great, but I'll probably go with only 8 DINs i.e. 1 chip. Could software support routing them to track inputs? Great :D Will have to think on that.... Cheers

Hi TK, Thanks for your input as ever. Aha, I should have mentioned that I was considering using an AIN. Would that be feasable i.e. could MBSeq scan AINs? I will make sure that the modular voltages don't exceend the AIN specs of course.... Great! I had been looking at the section controls source code, but I'd really like something at the step level, whereas the section control seems to be limited to 16 subsections. Can I say both? :smile: I guess no.1 is closer to my original intention, but having 2 would be great as well..... Were you referring to the idea of using DINs to step through the track with this last comment? Hmm interesting idea that I hadn't considered. From my (very!) basic understanding of the code, this could potentially be another type of FX. @TK: Is that an option? Cheers David

So I've been thinking about how I want to integrate MBSeqV4 further into my analogue modular synth workflow and I would like to ask if it would (theoreticaly) be possible to have an external analogue input to control which step of a track is playing. In other words, you could input a ramp wave into the AIN and that would control which step of a track is output. 0v = 1st step, 5v = last step. Things get interesting when you input other waves :D What started me thinking about this is the Milton sequencer from Peter Grenader, which provides for voltage control of the step (see http://web.archive.org/web/20110708110112/http://www.buzzclick-music.com/about_milton.html for more detailled description if you're interested) Secondly, would it be possible to do a similar thing with DINs i.e. have DIN control the clock stepping a track? This would probably require a second DIN for reset as well to make things gel well with analogue sequencers.... I realise this is all a bit outside of the inteded use case for MBSeqV4, but am interested if I should persue this idea with the current code or start something new :) David

Super great news, I would take 1 PCB please :)

Hi, I use the Microchip PICKit3 on both OSX and Linux to burn Midibox PICs. Using USB is nice and fast and a lot less problems than the DIY programmers I had built previously :) Dave

Bingo, this was the solution for me. Thanks a million TK! FYI, my default.cv2 file had this parameter blank. Editing the file and rebooting the MBCV was enough to get it working :D Expect some demo noises from MBCV2 soon.... Dave

Hello Thorsten, Thanks a lot for the info. I will check the things you mentioned this evening when I'm back by the hardware. One other thing I noticed is that when I run MBCV2, the MIOSStudio terminal shows this: [ 284.417] Init DHCP [ 284.517] [network_device_init] PHY initialized and then constantly displays messages like this: [ 286.420] 144 uS (max: 163 uS) [ 287.421] 139 uS (max: 152 uS) [ 288.423] 140 uS (max: 152 uS) Is that correct? Does it mean that I also have to use the Ethernet connection? Thanks Dave

I spent some more time testing this today, here's an update: I have added an SDCard and also tried with Ethernet. I have recompiled, made sure I chose the correct processor and updated to the latest bootloader. No change to MBCV behaviour. I have uploaded MBSeq v4.77 and can run the caliout tests successfully, I get the correct voltage on every pin of the AOUT. Also ran the testaoutpin commands to check the connections are OK, everything passes fine. When I upload MBCV to the LPC core board, MIOS terminal shows me: And I tried to run the caliout test with MBCV uploaded and nothing on the AOUT pins. So my conclusion is that the hardware setup is good, something is weird with the software. Current questions: Is there some way to choose exactly which AOUT module to use? Could anyone verify that my method of testing in the first post is correct? If not can anyone provide a simple example of how to create a MBCV2 patch that will for sure generate voltage from an AOUT pin? Dave

Hi gang, I'm trying to use MBCV2 and am having some problems. The firmware seems to be uploaded OK, as MIOSStudio reports MidiboxCV as a USB device. I'm using an original AOUT, it was previously tested and working fine with my STM32 based MBSeqV4. I am connected to the LPC core running MBCV2 via USB and have set the Lemur daemon to route the MidiboxCV MIDI device to Lemur in and out 0. Communication from Lemur on iPad seems to be working OK, i.e. I can change settings on the different CV channels and the surface updates - so communication seems to be working. My basic test is to make sure I'm on CV channel 1, set the LFO amplitude to max, then the -> CV to max. I would expect to see CV on output 1 of the AOUT, but so far nothing. I'm not sure if: MBCV2 needs a hardware config file on the SD Card ala MBseq to configure the type of AOUT settings etc? MBCV2 is OK with just the USB MIDI connection or if Ethernet is required for full OSC communication? Thanks in advance for any help

+1 to this. sometimes I can't switch it off.and my DAW is always on record :smile: looking forward to some tutorials TK!

Not sure if this is relevant MaG2k, but I had a similar problem going between Inkscape and Illustrator. The root cause was that one piece of software works at 72 DPI, the other at 90 DPI by default (I forget which is which). If you change the DPI setting so that it is equal in both applications, then exchanging .svg between them should not result in size changes.

Personally I just copy tracks that I like and then modify the copies. I was wondering what your goal was with this? I'm interested what different outcome you were looking for that a copy wouldn't achieve. TK, one thing that Luke's post got me thinking about: quite often I'm using a track which is set as an arpeggiator and play a certain set of keys that generate a great pattern. Problem is, next time I send any more MIDI to the track I lose that great pattern and can't remember or replay those last notes! Generally I always record the output of MBSeq because of this. I was wondering if there would be some way to address this in the sequencer itself? Maybe a way to grab the last set of notes the arpeggiator received and paste them into another track? Or to freeze an arpeggiator when you are happy with what it's generating? Anyone else found ways around this? Dave

When I ran into similar issues combining an older application with a newer bootloader, this helped me to fix it: taken from this thread: I used the second option and it fixed it.

Assuming they test out OK, I will take a PCB. Thanks for offering :smile: