TK.

Fantastic work! :) Best Regards, Thorsten.

Max/Msp can handle MIDI messages as well. The advantage of OSC is the more comfortable and more flexible usage, but it isn't faster (in distance, it loads your PC as well as the STM32 core more than compact MIDI messages). However, STM32 is fast enough so that you won't notice a drawback on typical usecases. Why not connecting your TG77 directly to the STM32 core? ;) You can set the program change in a mixer map, and a mixer map can be combined with patterns in "phrase mode" An OSC method could be implemented which allows to modify the mixer map via OSC messages. Yes, no problem - OSC path "/aout/<port>/<channel>/value" Yes, thats possible - I already tried this with my STM32 based OSC->CAN bridge, which acts as a proxy between Reaktor and MBSID V2. But I noticed that the CPU usage of Reaktor increases dramatically once the LFO waveform is sent with an update rate of more than 1 kHz. This wasn't an issue while sending the LFO waveform via MIDI. The issue could somehow be related to the ethernet driver of my Mac, or to Reaktor itself. I haven't tried this under Windows yet... Best Regards, Thorsten.

my early work - most .sid files are only remixes created with a selfwritten C64 based SID tracker (of course) - at this time I already noticed, that sequencing without a sophisticated control surface is hopeless due to my underdeveloped musical talents ;)

Hi Dave, the MBSEQ V4 firmware is in a pretty good state meanwhile - all functions I've implemented so far are working flawlessly, and whenever I find the time (currently not so often...) I'm able to add new features with much less effort than with the old PIC based firmware. I also already did some experiments with OSC via Ethernet and don't see a blocking point. E.g., I controlled the motorfaders/buttons/LEDs of my MBLC via OSC datagrams from an Reaktor environment, and I also tried an OSC->CAN bridge which works fine. So, for the MBSEQ V4 controlling the BLM matrix via OSC wouldn't be a big task, maybe 15 lines of code since the OSC parser is implemented in a very generic (and flexible) way. Also increasing the number of BLM lines isn't a big problem (from the software side), as the driver provides parameters to define the number of rows and columns. MBSEQ V4 itself will be able to send and receive OSC messages via ethernet. The configuration has to be done in a (simple) .c program, because this is much more flexible (and less RAM consuming) than providing a configuration file which is read from SD Card - this also means, that there won't be a limit to customize the OSC server/client for your own needs. Example for sending a button value: ///////////////////////////////////////////////////////////////////////////// // Send a Button Value // Path: /cs/button/state <button-number> <0 or 1> ///////////////////////////////////////////////////////////////////////////// s32 OSC_CLIENT_SendButtonState(mios32_osc_timetag_t timetag, u32 button, u8 pressed) { // create the OSC packet u8 packet[128]; u8 *end_ptr = packet; u8 *insert_len_ptr; end_ptr = MIOS32_OSC_PutString(end_ptr, "#bundle"); end_ptr = MIOS32_OSC_PutTimetag(end_ptr, timetag); insert_len_ptr = end_ptr; // remember this address - we will insert the length later end_ptr += 4; end_ptr = MIOS32_OSC_PutString(end_ptr, "/cs/button/state"); end_ptr = MIOS32_OSC_PutString(end_ptr, ",ii"); end_ptr = MIOS32_OSC_PutInt(end_ptr, button); end_ptr = MIOS32_OSC_PutInt(end_ptr, pressed); // now insert the message length MIOS32_OSC_PutWord(insert_len_ptr, (u32)(end_ptr-insert_len_ptr-4)); // send packet and exit return OSC_SERVER_SendPacket(packet, (u32)(end_ptr-packet)); } [/code] On a similar way you will be able to generate messages sent by the sequencer itself. Arduinome: you have to consider, that Monome (and derivatives) always require a PC based proxy to convert text messages into OSC datagrams. This means, that it doesn't really matter if the HW device itself sends MIDI or text messages or any other format, since a proxy has to convert them anyhow. Therefore - so long a proxy is used anyhow - I don't really see an advantage if the HW sends text based messages instead of MIDI messages. In distance, using MIDI messages would speed up the transfers, since they are more compact (IMHO a design flaw in Monome) For MBSEQ this means: so long it isn't a problem for you to use a proxy (like for Monome) to convert a datastream into OSC messages, you could use the common MIDI protocol, sent via USB (-> superfast!) This also has the advantage, that you can configure OSC messages in the proxy (very flexible, as the firmware doesn't need to be touched) If you prefer a standalone OSC solution which works without OSC proxy, and is able to send directly to ethernet, the "true OSC" option for MBSEQ could be interesting for you which only requires a MBHP_ETH module in addition. Components: the old Frontpanel can be re-used. An improved (and easier to build) frontpanel is provided by Wilba. Only the core module has to be replaced by MBHP_CORE_STM32 A SD Card is strongly recommented (no support for BankSticks anymore) And MBHP_ETH is optional The MBHP_CORE_STM32 PCB itself is final - SmashTV is still working on a solution for providing presoldered STM32s when shipping the kits, which saves you from soldering SMT parts Best Regards, Thorsten.

Hi, the PIC based MIOS doesn't allow you to add interrupt handlers (this has changed in MIOS32) This means, that the timer overrun flag has to be polled by a routine which is executed periodically (e.g. from the USER_Timer hook, if it is called more often than the target interval of TMR0) Under http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_sid_v2%2Fsrc%2Fsid_se.inc You will find a very simple example - the BPM generator is executed from USER_Timer each mS, but it uses it's own time base TMR0 ;; check timer0 overrun flag BRA_IFCLR INTCON, TMR0IF, ACCESS, SIDSE_Clk_NoInc bcf INTCON, TMR0IF ; clear overrun flag SET_BSR TIMER0_RELOAD_L bcf T0CON, TMR0ON movf TIMER0_RELOAD_L, W, BANKED ; (dummy add to update TMR0H, and to get carry flag of addition) addwf TMR0L, W ; (update TMR0H) movf TIMER0_RELOAD_H, W, BANKED addwfc TMR0H, F movf TIMER0_RELOAD_L, W, BANKED addwf TMR0L, F ; 16bit register update takes place with this write bsf T0CON, TMR0ON SET_BSR SID_BASE SIDSE_Clk_Inc ... your code which will be executed periodically SIDSE_Clk_NoInc [/code] TIMER0_RELOAD_[LH] defines the timer interval: 0x10000 - (interval / (2*100 nS)) e.g., a reload value of 0xc000 leads to an interval of 3.277 mS Initialisation in USER_Init: [code] ;; ensure that timer0 interrupt not enabled bcf INTCON, T0IE ;; internal clock source, 16bit, prescaler 1:2 movlw (1 << TMR0ON) movwf T0CON Best Regards, Thorsten.

You have to post your public DSA key here: http://www.midibox.org/forum/index.php/topic,10644.0.html Best Regards, Thorsten.

Meanwhile I got more requests than available GM5 chips - so, the preorder phase has started again! I've still some GM5 chips in stock, and I'm waiting (again) for people to pay their order. Deadline is next monday. Best Regards, Thorsten.

Die Nullen tun nicht weh. Allerdings befindet sich in Deiner Doku noch ein Fehler: das 64k Derivat heisst PIC18F4620, und es ist nicht 1:1 binaer-Kompatibel. So werden die ADC Kanaele bspw. nur mit der MIOS Version im pic18f4620 Verzeichnis richtig initialisiert. Ein PIC18F457 wird nicht unterstuetzt (gibt es den ueberhaupt?) Solange man den Dump auf das gleiche Derivat aufspielt, sollte es keine Probleme geben. Gruss, Thorsten.

To have the same understanding: the MBSID firmware is doing *much* more than simply bridging a MIDI synth to the SID chip. You won't achieve the same possibilities by controlling the SID from external. Best Regards, Thorsten.

It's somehow cool, but it leads to borring results. You will really miss the mighty MBSID sound engine :) However, some time ago I did some experiments with controlling SID registers directly via OSC protocol. The MBHP_CORE_STM32 module is used as an Ethernet->CAN proxy: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fmisc%2Fmbsid_can_osc_proxy%2F This allowed me to write into the registers of up to 8 SIDs from an Reaktor environment. OSC Path: /sid<sid>/<l|r>/<1|2|3>/direct/frq, .../pulsewidth, .../ctrl, .../adsr E.g., "/sid1/l/direct/frq 440.0" to change the frequency of SID1, left channel to 440 Hz, or "/sid*/*/direct/adsr 0 0 15 0" to change the envelope parameters for all SIDs There is also a path to control the gates of all SIDs with a single message. I was able to play an additive synth (24 voice organ sound! :)) directly from Reaktor, even FM and PW modulation from Reaktor was possible :) Alternative solution: use the ASID protocol, which allows direct access to all registers as well. It works with SysEx messages, is the fastest solution for UART based MIDI and is already part of the MBSID V2 firmware (no additional core required) -> http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_sid_v2%2Fsrc%2Fsidplay.inc But the resulting sound is very C64 like due to the slow update rate of max. 70 Hz. However, some people like this ;) Best Regards, Thorsten.

The specified pulsewidth for the CS# and WR# input (tCSW and tWW in the datasheet) is 100 nS. The MBFM_REG_Write routine generates a pulse of ca. 200 nS to be on the safe side, but it could be that with such a long cable the pulse will be shorter due to the higher impedance, accordingly the required timings will be violated. It would be interesting if it works better with long cables if more than one NOP is inserted between CS=0 and CS=1, e.g. try: bcf MBFM_LAT_CS, MBFM_PIN_CS ; activate chip select line nop nop ; + 100 nS nop ; + 100 nS bsf MBFM_LAT_CS, MBFM_PIN_CS ; release chip select line [/code] Note that this change has to be done at two places. Best Regards, Thorsten.

Too bad, it was such a nice logical explanation ;) This shouldn't be a problem so long the bipolar PSU is powered on before the application is booting, because the driver will reset the YMF262 in MBFM_REG_Init to ensure defined starting conditions before OPL registers will be initialized. Best Regards, Thorsten.

You've now access to the programmers section of this forum, where you will find the informations to get SVN access. Best Regards, Thorsten.

The unique ID isn't explicitly forwarded by MIOS32, the calculation is OS dependent (e.g. by name, vendor/product/device ID, USB node, etc...) Best Regards, Thorsten.

I think that I found a logical explanation for this failure effect. From the beginning: first I had the idea, that this failure could happen if D6 and D7 are clamped to 0V, since bit #6 and #7 of address 0xc0..0xc7 control the audio channel C/D assignments. But by "forcing" these bits to 0 via SW there was no sound at all. But I didn't give up and tried out other bits forced to 0. Finally with D2 forced to 0 I noticed the described behaviour: I hear a sine sound on Channel A and B, but not on Channel C and D So - could it be that our hero forgot to run the interconnection test completely before asking for support in the forum? ;) And could it be, that our hero cannot differ between a 1kHz sound, and a ca. 500 Hz sound? (because with D2 forced to 0V the resulting frequency is ca. one octave lower) ;) I'm curious - unfortunately this nice explanation doesn't work if I try this out on the MIDIbox FM firmware - most patches sound completely wrong. /Edit: another possibility - maybe our hero swapped two data lines? Best Regards, Thorsten.

First of all it's important to use the "18f" version which can be found under http://miostools.midibox.org/ If SysEx transfers are unstable with this version, it could be related to a Windows driver issue of your MIDI interface (SysEx blocks > 256 bytes not transfered completely). Miditrix helps to overcome this - some informations can be found here Best Regards, Thorsten.

It's like you are trying to open a .mp3 file on your computer, but no MP3 player is installed... You've to upload the midibox64 application. Best Regards, Thorsten.

I checked the testtone application on my MBFM to ensure that this isn't related to a SW issue - it works, all 4 channels output the 1kHz sinewave Best Regards, Thorsten.

ENS->SID If you don't like the cumbersome usage, add SID buttons! Best Regards, Thorsten.

Chaining up to 16 DIN SRs is a physical, and not a software limitation. See also this posting However, beside of the possibility to use a button matrix with the old PIC based solution (1024 buttons or even more buttons? no problem) with MIOS32 it's much easier to scan a second DIN chain with less programming effort because of the flexible framework (e.g. generic SPI access functions) and C as a programming language instead of cryptic assembly code. It's definitely worth to wait for the public release (some people are already using the MBHP_CORE_STM32 module) Best Regards, Thorsten.

Thank you.

You are right... pin #28 was the intended one. To summarize: you've checked the SID itself, the amplifier, the control signals between 74HC595 and SID, the 5V/12V supply voltage - so: almost all pins, and they are ok. Remaining pins are #1..#4 (caps) can only be checked visually (should be easy!) Pin #6 (the clock pin) is connected to CORE::J10:PWM. On the core, it's a routed to Pin #17 of the PIC. Depending on the PCB you are using, a cable is required as a bridge (see also this picture - the red marked connection) - did you consider this? /Edit: a better picture Best Regards, Thorsten.

Ok, last possibility: measure the voltage between pin #14 and #24 #28 when the SID is plugged in. For a 6581 it should be 12V Best Regards, Thorsten.

Yes - so it seems that your SID isn't working. From where did you get it? Are you able to test it on an old C64? Best Regards, Thorsten.

The 74HC595s can be tested with the mbsid_interconnection_test application. See the README for details about the test procedure. Best Regards, Thorsten.