Jump to content

Search the Community

Showing results for tags 'sysex'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Top
    • Latest News
    • Bulk Orders
  • Construction
    • MIDIbox NG
    • MIDIbox HUIs
    • MIDIbox SEQ
    • MIDIbox SID
    • MIDIbox FM
    • MIDIbox BLM
    • MIDIbox User Projects
    • MIDIfication
    • Design Concepts
    • Parts Questions
    • Testing/Troubleshooting
    • Tips & Tricks
    • MIDIbox Documentation Project
  • Software
    • MIDIbox Tools & MIOS Studio
    • MIOS programming (C)
    • MIOS programming (Assembler)
    • MIOS toy of the week
  • Miscellaneous
    • Fleamarket
    • Sale Requests
    • Miscellaneous
    • Songs & Sounds
  • Archive
    • Parts Archive
    • MIDIbox of the Week
  • Multilingual
    • Nordisk
    • Nederlands
    • Deutsch
    • Français
    • Italiano
    • Español
    • Português
    • Greek
    • Russian
    • Others

Blogs

  • Twin-X's Blog
  • j00lz - MB-6582 Build Log
  • Project "Desire MC1"
  • MIDIbox Live
  • protofuse's Blog
  • Joeri's Blog
  • Phil's MBSEQv4
  • taximan's home base
  • Kyo's Blog
  • Snoozr's Notes on Building an MB-6582
  • Amplification
  • dawidbass' Blog
  • SLP's Blog
  • MidiSax's Blog
  • blog_latenights
  • Non usare un modulo Lcd
  • Duggle's Blog
  • Rics' 4Decks
  • aaa135139's Blog
  • bilderbuchi's Blog
  • Alain6870's Blog
  • MidiMaigre 37
  • Digineural's Blog
  • Sylwester's Blog
  • olga42's Blog
  • MB9090 Blog
  • Zossen's Blog
  • stilz&Rumpel's Blog
  • Antichambre's Blog
  • MB TWINsid Blog
  • massenvernichtungswaffe.de
  • gslug's Blog
  • albpower2seq4sid's Blog
  • TB's MIDIBox Adventures
  • kHz-tone's Blog
  • Blatboy's Blog
  • geth's-building-stuff-Blog
  • Excursions in DIY land
  • Ralex's Blog
  • huanyupcb's Blog
  • Vicentiu Mincior's Blog
  • A journey through midibox LC construction
  • TheAncientOne's Blog
  • nebula's Blog
  • Sasha's Blog
  • Tales from the kit mill
  • novski's
  • nicolas' Blog
  • Gelpearl
  • Johan's Blog
  • midibox.org Blog
  • Wisefire build logs
  • ColleenMorris' Blog
  • brucefu's Blog
  • atribunella's Blog
  • Building my Seq
  • A Seqv4 kind of thing
  • ModulBox
  • ArumBlack
  • mongrol
  • Watch!!- Mission: Impossible – Fallout (HD) Movie Online.Full 4k
  • Watch!!- Hotel Transylvania 3 Summer Vacation (HD) Movie Online.Full 4k
  • Silver eagles sign football gamer Adam Zaruba since restricted stop
  • Watch!!- The Meg (HD) Movie Online.Full 4k
  • Steelkiwi Blog
  • Words1234
  • SSP
  • How to Solve the Excavator Hydraulic System Running Slowly
  • Eight Ways to Maintain Excavator Parts
  • Five Common Problems and Fault Analysis of Komatsu Excavator
  • Ficher Chem Co. Ltd: Buy Research Chemicals Online
  • Zazenergyli
  • Top Mobile App Development Company in USA
  • belkin range extender
  • wrong post

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 11 results

  1. I was wondering about how the pre-definition of the SysEx STREAM_MAX_SIZE variable (as 128) in mnbg_event.c came about. The reason I am asking is that I have recurring problem with [MIOS32_MIDI_Receive_Handler] Timeout on port 0x21 which, as I have found in other posts, means that there is an overflow on MIDI In 2. In my setup this is the "return" port of a hardware synthesizer, that I am controlling with control elements on another MIDI hardware device (bidirectionally connected on MIDI In/Out 1). While switching through various editing modi on device 2 it always sends a SysEx dump of the parameter values currently set in the selected program/patch. I am reading these values with syxdump_pos=x:y, syxdump_pos=x:y+1, ...., syxdump_pos=x:y+n and assigning them each to a control element on device 1. This setup shows me that the SysEx dumps is (always) cut off at syxdump_pos:x:52. This confuses me, as I can not explain why an overflow, and a subsequent disposal of further incoming bytes, happens so early, since the MAX_SIZE is set to 128... Of course there are probably some additional messages being transferred (like Ack messages for the successfully received dump request etc.), but still this does not make much sense to me. I tried to cope with this by increasing the STREAM_MAX_SIZE in mbng_event.c to 256. Same result , though. I can't come up with any other to deal with this I must honestly say. Has anyone else experienced similar problems when handling the transfer of SysEx parameter dumps? I'd love to hear your thoughts about this. Greetings, Micha
  2. I found some posts here with similar thematics, but it did never seem quite covered for my application case, so I thought I'd start a new one.. I am reading and processing a program parameter dump from a hardware synthesizer, and some of its parameters are woven into one single byte of the dump (for example the activation and polarity of certain envelope parameters can be (de-)activated/polarity-switched). And since I want to control these parameters from a hardware controller, I need to read and display the, currently set, values on the controller's displays. That is why I am calling syxdump_pos=x:y a lot... It would therefore be perfect to have something like syxdump_pos=x:y:z to call for subdivisions/single-bits. I guess the way to achieve this would be altering the MBNG_EVENT_NotifySyxDump function in in the mbng_event.c file, but I'm not sure how to approach this... Has anyone else ever done anything similar? Or maybe found another way around it?
  3. So at one point during my development of an app on NG basis on a STM32F4 core, my SesEx tool stopped working. I used it to send messages to both a Mackie C4 and a Korg M3R, which both responded in the beginning. The confusing thing is, that I can still communicate with both via my .ngc and .ngl scripts. I address them both by their ports (Macke on MIDI port 1 = 1000100000001000; M3R on MIDI port 2 = 0100010000000000) and there it works! Still something must have been misconfigured on the way and I can't imagine what, because I'm still pretty much in the beginning. I also used to get SysEx dumps form the M3R on request, which also stopped working..
  4. So I am planning to build a microcontroller as an interface between a Mackie C4 Pro and, theoretically, any kind of Hardware/Software component. The component that is to be controlled will be determined, and the configurations specified, by templates which will be stored on an SD card. To realize this I will be using the STM32F4 module with the SD card interface and a MIDI 2x2 module. Eventually another 2x2 is planned to additionally connect a MIDI keyboard. I am a newbie to the MIDIbox forum so I started researching and decided to take the NG project as a starting point. To me this means that in order to implement this I need to alter the .ngc .ngl and .ngr files to a) have a communication with the Mackie that will, basically, always stay the same and b) generically prepare the other side of the microcontroller so that the user can specify the mappings to his hardware/software himself. RPN, NRPN and SysEx must be possible. This of course means that the chosen parameters and their state will be required to be displayed on the Mackie's displays, which, after reading the NG and STM32F4 specifications, I think is possible. A final requirement is that the configurations will have to be stored into a textfile (I was thinking XML) so that the user won't need to actually open the .ngc files and do his settings there, but rather that on startup the device considers the textfile as belonging to a certain configuration file, checks if something was altered in the textfile, if so applies it to the configuration data and then sets that up as the current configuration state. What do you guys think? Does that sound possible? Did I choose the right components? And has anyone ever done something similar and encountered problems that maybe I could encounter too?
  5. Hello all, For the past week or so, I've been trying to learn my way around SysEx for the purpose of setting up a Behringer BCR2000 to program the sammichSID. After much trial and error, I have had some success, but I have hit a wall with the Voice Envelope ADSR. Since Attack/Decay and Sustain/Release each share a respective address, I can't sort out how to control them independently without issue. Currently, I am using the BC Manager software (https://mountainutilities.eu/bcmanager) with the help of the SID Ctrlr panel to send the following data (for OSC 1 L/R): Attack: $F0 $00 $00 $7E $4B $00 $06 $01 $00 $62 val4.7 val $F7 Decay: $F0 $00 $00 $7E $4B $00 $06 $01 $00 $62 val0.3 val $F7 *Edit* - I am sending a value range of 0-15 for each. This gets me part way there, but I am unable to have independent control over them. If I move the encoder I've assigned to Attack, it will affect the Decay value as well. Here is the relevant part of the SysEx implementation (https://github.com/midibox/mios8/blob/master/apps/synthesizers/midibox_sid_v2/doc/mbsidv2_sysex_implementation.txt) Line 354: 0x062 | [7:4] DCA Attack Rate | [3:0] DCA Decay Rate I'm sure I'm missing something simple. Hopefully this makes sense to someone! :) Thank you for reading, and any help is greatly appreciated. Dhayv PS - side question: in the hex above, what does the $06 $01 $00 represent? I have noticed it is included in almost every parameter I have come across so far.
  6. hi all, i posted this question in the troubleshooting section first, but jaytee recommended to post it here to call more attention- i have a strange problem with my sidbox; it seems it does not send any sysex messages. my setup: -macbook with 10.9.5 -neusonik im/one midi-interface (successor of the uMIDI/O22 on the whitelist, claimed to be technically identic) -sidbox (one core, two sids, latest firmware (v2_044)) Uploading the firmware works fine and i can also send patches from computer to sidbox (e.g. taken from the vintage bank). But if i click "receive patch" or "receive bank", the sidbox only sends short stuff like "F0 00 00 7E 4B 00 F7" or "F0 00 00 F7". Same thing when trying to dump with "shift+button5" from the sidbox CS. The different patch editors (tried jsynthlib, ctrlr and the MBSIDV2-Editor) also need bidirectional sysex, so don't work either. i tried with another synth (ML-303; i think TK took a hand in this one, too :-D) to check if it is caused by the midi interface (or something else inside OSX or the software), but with this one, i can store/dump patches in both directions. i'm a bit perplexed; getting "Application is up & running!" and clock ticks indicates that the sidbox's midi-out port is working and there is no wiring error (there is only one TX-pin on the PIC..); the test with the 303 indicates that my midi-IF/computer/software setup should properly transmit sysex data in both directions. So why can't i get data from the sidbox? is there any option i could have missed? any ideas? regards simon
  7. i have a strange problem with my sidbox; it seems it does not send any sysex messages. my setup: -macbook with 10.9.5 -neusonik im/one midi-interface (successor of the uMIDI/O22 on the whitelist, claimed to be technically identic) -sidbox (one core, two sids, latest firmware (v2_044)) Uploading the firmware works fine and i can also send patches from computer to sidbox (e.g. taken from the vintage bank). But if i click "receive patch" or "receive bank", the sidbox only sends short stuff like "F0 00 00 7E 4B 00 F7" or "F0 00 00 F7". Same thing when trying to dump with "shift+button5" from the sidbox CS. The different patch editors (tried jsynthlib, ctrlr and the MBSIDV2-Editor) also need bidirectional sysex, so don't work either. i tried with another synth (ML-303; i think TK took a hand in this one, too :-D) to check if it is caused by the midi interface (or something else inside OSX or the software), but with this one, i can store/dump patches in both directions. i'm a bit perplexed; getting "Application is up & running!" and clock ticks indicates that the sidbox's midi-out port is working and there is no wiring error (there is only one TX-pin on the PIC..); the test with the 303 indicates that my midi-IF/computer/software setup should properly transmit sysex data in both directions. So why can't i get data from the sidbox? is there any option i could have missed? any ideas? regards
  8. hi my idea is: put a *.syx on the SD-Card put the SD-Card in a STM34F4 core var a. Core recognizes a *.syx and send it out on Port 32 (Midi A) var b. I activate something in the program (with a Dip switch for example) and now it loads up for what: in use with generic Midicontrollers (BCR2000) to transfair a CC-Layout that is fitting to the Midibox programm for which project: http://wiki.midibox.org/doku.php?id=msq-cc-bcr what i have up to now... char filepathL[8]; //Number of Pathsymbols tm/bcr.sys >>> 8 max! MUTEX_SDCARD_TAKE; statusDir = FILE_DirExists("syx"); MUTEX_SDCARD_GIVE; if(statusDir != 1) {MUTEX_LCD_TAKE; MIOS32_LCD_DeviceSet(0); MIOS32_LCD_Clear(); MIOS32_LCD_PrintFormattedString ("%s %d", "no bcr.syx", statusDir); MUTEX_LCD_GIVE;} if(statusDir == 1) { sprintf(filepathL, "tm/bcr.syx"); FILE_ReadOpen (&midifile_fi, filepathL); //normally i then start by reading the content and transfair it into variables..... but happens if i have Sysexfile instead? how to tunnel this to midiport? FILE_ReadBuffer((u8 *)file_typeBank, 4); //"MQ01" = 4 Positons FILE_ReadBuffer((u8 *)CC_SEQ, 32); //Container for static not touchable Variables FILE_ReadBuffer((u8 *)CC_Morph, 128); //Container for morphable Variables FILE_ReadBuffer((u8 *)Velo_Morph, 256); //Here we have 8x32=256, FILE_ReadBuffer((u8 *)CC_Store, 256); //Here we have 8x32=256, FILE_ReadBuffer((u8 *)MSQ_Store, 65536); //Motion-Sequence-Data 8x32*256=65536 FILE_ReadClose (&midifile_fi); MUTEX_SDCARD_GIVE
  9. Hi! Since there is no Wavetable Editor in Ctrlr for the lead engine yet, i made one in PD. I attached a simple Patch that just writes into the patch-buffer. The second also reads from the buffer or from saved patches (*.syx). You will need Pd-extended to run the patches. Editing the wavetable is done by drawing around. I kept these patches as simple as possible, so you can use them as a starting point and add other sysex functions, ipad-support (via osc), reversing, scaling, harmonizing,... ( try py/pyext) by yourself, before porting it to Max for Live. tested on Mac OSX and Linux ( Raspbian ) have fun Jens sid_wavetable_editor.zip
  10. I decided to go ahead and try to write my own sammichSID patch editor for the GURU Renoise tool. There's one slight problem - I have no *$%$% idea what I'm doing. I'll explain my dilemma... After some research I see that someone already created a GURU script for sammichSID. Great! It uses CC messages, but because the Sammich does NOT save CC changes to the patch buffer this does me absolutely no good. Not so great. So I see there is a Ctrlr panel for MidiboxSID/sammichSID. Great! It is buggy at absolute best. Not so great. I'm using Vista, and to put things simply, the Ctrlr panel does things at random or whenever it feels like. So here I am with a wonky knob on my Sammich due to overuse. A patch editor is absolutely necessary because I'm at a point where all I can really do is play notes and change patches. I looked, studied, read, reread and tried to generally wrap my head around the MidiboxSID sysex documentation located here: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_sid_v2%2Fdoc%2Fmbsidv2_sysex_implementation.txt After hours (possibly days) of trying things out, I managed to get it half working. Even that is pushing it. tl;dr - Someone please help. ---------------------------------------------------------- Here is what I know (or don't) so far... Someone please correct me if I am wrong. The manual states that the sysex format for patch editing is: F0 00 00 7E 4B <device-number> 06 <WOPT> <AH> <AL> <value_l> <value_h> F7 So let's say for example's sake I set the device number to "0" and ignore the <WOPT> for now. Let's also say that I would like to edit the volume on the lead engine. The manual says: 0x052 | [6:0] Volume (0-127, only most significant 4bits are used by SID) Now this is where I'm completely ^&*$^*# up. The manual doesn't really make clear what [6:0] means. Furthermore, the manual says: (<AH> = 0..3, <AL> = 0..7F) Patch address: (<AH> << 7) | <AL> ...in the description of the patch sysex layout. I have NO idea what this means and it's not really obvious (to a newb) where to find this information. As a workaround I loaded Ctrlr to see what it was sending in the MIDI monitor window for volume/lead engine control. [f0 00 00 7e 4b 00 06 00 00 52 0f 07 f7] ...is what it was displaying, with the two value bits (0f, 07) changing, of course. I'm still confused on how this string relates to what was posted above. So I open GURU and enter: sysex_message_template = {0xF0, 0x00, 0x00, 0x7e, 0x4b, 0x00, 0x06, 0x00, 0x00, "nn", "vv", 0xF7}, number = 52, max_value = 127, ...where nn=number and vv=value. I've tried both hex/decimal values without success. Other times where I did get it to do something, GURU would jump 100 values or so, making it useless. So I please ask for some input on this. I'm determined to write out a new patch editor, but I cannot seem to get past the learning curve of sysex.
  11. Hi folks, I am building a sammichSID from the recent batch and have an issue. I am at the stage where I am trying to use MIOS Studio to speak to the Sammich. After turning on the Sammich while plugged in, I saw a single f0 00 00 7e 40 00 01 f7 message in the MIDI In window. And now when the Sammich turns on I get "MIOS V1.9" and then "Ready." When querying I received a "No response from MIOS8 or MIOS32 core!" message and started following the Troubleshooting guide. So when testing my interface via Loopback, I got a detected feedback loop. Good! But when I tried to send a SysEx command, I didn't get an echoed response. In other words, I fail at this step becaue the grey messages aren't repeated back in black: http://www.ucapps.de/mios_studio/mios_studio_feedback_sysex.png So I tried my 2 other interfaces on both my Mac and PC, no luck. I even went out and bought a fourth device on the whitelist (the MOTU FastLane USB). No luck (and $60 bucks down the drain). I must be missing something... Please help!!!! I have been reading alot about Mandolane maybe helping here, but the mandolane website appears to be offline :( EDIT Oh one more note, when sending these messages, the LEDs for both input and output light up on the MOTU device. So I feel like some kind of filtering must be happening on the software end. Or maybe I just need better Java MIDI drivers? When I route through my Sammich and Query, I do NOT get input LEDs to light up. So maybe there is another problem, but I figured I would start with the loopback.
×
×
  • Create New...