Sonar 8 SearchBack function not working ==> sending incorrect Patch change MIDI events

Wow!
What about cutting 90% out of your post and sticking to the essential?  For one I don't have the energy to start analyzing a novel like that :o/

I stopped reading after the first run-on sentence

2 posts?

Sounds like a troll to me.

I will await clarification (or vilification - let's see which one happens first)

sorry about the overly long post and making u read my entire experience, but I've been a Cakewalk user for 20 odd years and this is my 2nd post in my life on forums. I don't go to forums often coz it takes time (and time is money) to read posts they remind me of BBS days in days of C64/Amiga/Atari where users post opinions/rants/rumours/flame wars and the like. let's be clear: we electronic musicians only have a certain amount of time slices in our working lifes to enjoy making music or go to forums and post long messages. and when we post a message it is usually coz we're stuck on a problem that cannot be resolved.
 
I just want to describe a typical HW synth + MIDI setup that is quite trivial - nothing hokey-pokey about the way I am routing via physical MIDI cables. I use a 360 systems 8x8 MIDI patch bay to route a input to multiple outs, but on the HW synths themselves, I program them to filter channels (ie. turn them off) so the events for other channels that are for other synths sent on the same wire are not going to trigger the internal tone generator in multi-timbral mode. etc.
 
This is the same configuration that I used in past 10 odd yeasr, it works; ie. set up correctly as far as routing and PCG/bank change filternig / Rx channel is concern on performance-part basis.
 
I never had this problem in Sonar2: was never an issue and right now this is a roadblock in Sonar8 that I can't resolve myself, which is why I am here. 
 
 
 
 
 
 

Sonar8 sends RANDOM program change events whenever you start playback in middle of a clip

No, it doesn't. 


Seriously, if it did I would surely have noticed by now. The only time SONAR will send MIDI data to a synth that isn't actually in the MIDI track is when you've specified a patch using the dropdown listboxes in the track header. It will then send a patch-change to the synth when playback starts. Other than that, it only transmits what's in the MIDI track.

BTW I, too, am a fan of hardware synths - as are many others here - and the Triton is one of the more popular models, along with various other Korg, Yamaha, Roland and Kurzweil synths. We're all happily sending (non-random) patch-change events to them from SONAR.

bitflipper

Sonar8 sends RANDOM program change events whenever you start playback in middle of a clip

No, it doesn't. 


Seriously, if it did I would surely have noticed by now. The only time SONAR will send MIDI data to a synth that isn't actually in the MIDI track is when you've specified a patch using the dropdown listboxes in the track header. It will then send a patch-change to the synth when playback starts. Other than that, it only transmits what's in the MIDI track.

BTW I, too, am a fan of hardware synths - as are many others here - and the Triton is one of the more popular models, along with various other Korg, Yamaha, Roland and Kurzweil synths. We're all happily sending (non-random) patch-change events to them from SONAR.

=======================
 
I wish I can believe you, and that sonar8 works as per-design, but apparently I play my project from beginning to end, it works coz it is not searching backwards for the PCG change to fire it is PLAYING forward encountering PCG changes that I implanted on each track and it sends off 100's of these messages 100% flawlessly.
 
but the minute I stop playback on a particular measure, and start playing again it is playing some crap sound that was not intended - it is transmitting something that I DID NOT SPECIFY in the MIDI track.
 
on the LCD screen of my Triton or Fantom, I see the patch change in real-time when I playback midway of clip. bizarre.
 
I scan my MIDI events off the track using the MIDI LIST EDITOR but I don't see any rogue messages, so Sonar8 is sending them on the fly, and they are like "fantom events" that I cannot see via MIDI list EDITOR.
 
this is a good thing I don't rely on Sonar8 to make $$$ to make a living!! I wouldn't survive using Sonar8.
 
btw: like most, I was a big fan of the legendary best selling Korg M1, and I believe it got me hooked into this workstation-nirvana.
 
I believe KORG/YAMMY/ROLAND cranked out awesome made-in-Japan HW products but most are now legacy, but still offer great real-time response and real-time control knobs that make them more fun and authenticate then say, stupid mouse clicks to control SW faders or VCO/LFO freq's etc.
 
The S700 triple-strike vel-switched sample of the Yammy S90 was the sole reason why I plunked down $$$ for that board; and still my fav master controller keyboard, but the TRUE PIANO vst plugin of Sonar8 blows it away in terms of authenticy and resonance modelling and I can get as low as 4ms latency using WDM drivers, almost real-time performance.
 
the S90 hammer action feel + TruePiano VST plugin= not a bad compromise, but if I can only figure how to get Sonar8 to work propertly is another story....
 
 
 
 

bvideo


Do you think these symptoms are a problem of the size of your project? What happens if you solo a couple of the offending tracks and try to reproduce? Build it up little by little until you hit the problem. Alternatively, find a minimal project that reproduces and let other people try it out. Which 'x' of 8.x are you using? Maybe it was some time in the 8.x timeframe (8.3?) that the midi prepare buffer size got made configurable. The default may be too small; 500 ms is not bad. Also, in the old 8.x days the audio metronome would cause baffling problems. [DX7+E!, Roland D50+MEX, Korg M1REX, Ensoniq Mirage, ...]

 
I am using sonar 8.0 and I can adjust MIDI buffer (default=500ms); I increase to 750ms still same problem; I don't think it is buffer issue, coz the bug can reproduce with 1 SOLO track. so not load problem or max limit on number of MIDI tracks in a single project.
very easy to isolate the problem tracks to 1 or 2 prime suspects: to narrow it down to that pesky track = the only weapon I got: that's the first thing I usually do - SOLO individual tracks so that their MIDI event activity are enabled while others are not.
 
ie. I have 4 sonar MIDI tracks routed to EX5R I called them EX5R_1, EX5R_2, EX5R_3, EX5R_4 which is transmitting on USB MIDI OUT PORT B, channels=11,12,13,14, respectively. for that physical USB port (I only got 4 total to share among 10+ synths) : I reserve channels 1-6 for Trinity HDR, 7-10 for Roland VSYNTH, and I reserve channel 16 for my EX5R Performance Bank selection channel. so I multiplex several HW synths on a single USB port, then in each assigned MIDI channel, multiplex patch changes for that particular part of a particular synth. 
  
when I solo the 3 EX5R_2 to EX5R_4 tracks to see which is sending bad PCG change ==> I instantly can reproduce the problem,
 
I then SOLO and isolate to a single EX5R_2 track out of 100+ MIDI tracks, upon PLAY: I can see the EX5R synth's part associated with this channel receiving the ROGUE pcg change msg!!
 
also scanned all midi events on that cultprit track: via MIDI event list editor and I then remove all PCG change msg for that track, and start playing MIDWAY of clip ==> same problem! 
 
on this soloed MIDI track : consists of only MIDI note on/off events, no CC msgs, the searchback function should now be sending the DEFAULT PATCH assigned to the SONAR midi track but it is not : it is sending something else that it picked from the rabbit's hat - which is really baffling.
 
like I said, appears sonar8 has a mind of its own: a track with no CC msg yet sonar8 sends a rogue CC msg! 
 
also with this track SOLO'ed: I remove the possibiblity of OTHER MIDI tracks that are suppose to be routed to other HW synths like JD990 or FantomXR that incorrectly got routed to the EX5R and therefore received inadvertinely that incorrect PCG msg. 
 
the only way to get around this problem is to start from the start of the CLIP just before start of the PCG change msg; which is annoying if say I am 24 bars into a long passage, and now I have to rewind to beginning just to replay that section with the correct sound. 
  
I never get this problem in sonar2 and I wish I never encounter this problem and move on with my life.... (creating music not fighting baffling cakewalk software glitches).
  
  
  
 

Sounds like your slip edits are burying the sysex changes you have embedded in your clips. You may want to consider using a second track that only handles your patch changes rather than embedding them into your MIDI note data. That way your slip edits on the musical data won't affect your patch change messages. Alternatively, you are going to have to really pay attention to the MIDI event list to make sure the events that need to get sent to make a patch change are "active".

I used to work the way you do and now I simply stick to one track per patch. If I run out of channels, I commit what I have to audio, archive the MIDI track and reuse the channel. Frankly, with VSTs like Omnisphere, Kontakt and Ivory (and so on), I don't find that I run out of channels as much as I used to.

Regards,
Dan

dcumpian


Sounds like your slip edits are burying the sysex changes you have embedded in your clips. You may want to consider using a second track that only handles your patch changes rather than embedding them into your MIDI note data. That way your slip edits on the musical data won't affect your patch change messages. Alternatively, you are going to have to really pay attention to the MIDI event list to make sure the events that need to get sent to make a patch change are "active".

I used to work the way you do and now I simply stick to one track per patch. If I run out of channels, I commit what I have to audio, archive the MIDI track and reuse the channel. Frankly, with VSTs like Omnisphere, Kontakt and Ivory (and so on), I don't find that I run out of channels as much as I used to.

Regards,
Dan

 
it must be nice to ultra fast CPU + all those top end VST synths at the tip of your finger or mouse clicks, and yes since it's all in SW, MIDI channel is not real physical wire of 9 pins but just C code: a table of structures and pointers to a queue of track sequence of MIDI messages and I suppose the max # of midi channels per synth instance is limited by max RAM and RAM is cheap!
 
I am not doing any slip edits on a MIDI clip: there is no-use case for this operation. I edit all my MIDI clips in the good ol fashion Staff view, never Piano Roll or other views. this is a HACK FIX, not a permenant solution and I have to live with this baffling bug unless I want to throw my entire sonar+synth gig into the oceans.
 
I used to think if I were to have luxury of A SINGLE dedicated sonar midi TRACK to a SINGLE patch ==> say 16 HW synths using 16 performance parts maxed out = min 256 MIDI tracks I have to juggle, now even with single channel: say I get adventurous and I want to use 10 different patchs routed to that channel so I create more "shadow" channels, and only activate one at the time (since they all share a single MIDI channel assigned to a unique patch there is no way to activate all of them concurently).
 
once in a while I do a BOUNCE of a MIDI track to AUDIO WAV if and only if I need to, recording externally via Soundforge (I don't like sonar's primitive audio editing functions), convert to REX/cakwalk loop (if arp/drum pattern), and import as a dedicate audio track.
 
I try not to run too many audio tracks coz it consumes more CPU cycles and I want to save them for plugins. I also have limited real estate HD (500 mbytes) so cant afford to archive 10000 audio tracks when they are really simple ARP patterns and MIDI live playback should suffice.
 
I think I am like everyeone: trying to find the best/most efficient workflow solution and I know everyone has their own style of working with sonar. I definitely don't want to spend more time managing an audio media archive library then I need to.
 
also problem of having too many tracks ==> creates inefficient, slow workflow given sonar's non intuititive UI: which is what I am trying to maximize to reduce logistics/mechanics of daily operations.
 
I don't think I am going to be that brave: to spend insane amount of time scrolling up/down TRACK view or STAFF VIEW to navigate to a particular track in a project with 200+ AUDIO and MIDI tracks - unless cakewalk has a cool keyboard binding for a command to search for tracks narrowing down to those whose name begins with TRITON* or ends with **_SYNTH_ARP_pattern_FMajor_etc etc.
 
and sometimes I do have the track index memorized and I want to switch to that track using a customized key binding - but no no no imposible!
 
so if I want to switch to another track = I have to manually scroll up/down this huge list of tracks in Track view or Track Selection pop up box ==> cumbersome time consuming operation, and cakewalk thinks we're happy having to scroll up/down using mouse/key strokes on this Listbox of 200+ tracks. They should really port the linux "grep"-like Patch Search function from Track Property Dialogue to Track Selection dialogue.
 
 
 

Sonar 8.0?? Why didn't you do all the updates? There could possibly be issues with that version. All I know is 8.5 would not do that unless you put the patch changes there and they CAN be hidden from you as I mentioned in my first response. 
Are these all midi tracks created in Sonar 8.0 or are they created in older versions or other software? If so then you'll have to open the file in another sequencer and look in the event list there. Sonars  7 and 8.5 from my experience,  event list does not always show all patch changes if the MIDI file is imported. 

Cactus Music


Sonar 8.0?? Why didn't you do all the updates? There could possibly be issues with that version. All I know is 8.5 would not do that unless you put the patch changes there and they CAN be hidden from you as I mentioned in my first response. 
Are these all midi tracks created in Sonar 8.0 or are they created in older versions or other software? If so then you'll have to open the file in another sequencer and look in the event list there. Sonars  7 and 8.5 from my experience,  event list does not always show all patch changes if the MIDI file is imported. 

maybe I will upgrade, I just didn't want to de-install/re-install. I work song projects from scratch using sonar2 and then import sonar2 project files to sonar8, should not be an issue as far as conversion is concern; if it is indeed missing events in the track: sonar8 is then a premature non-professional software release. can you imagine Han Zimmers creating a next blockbuster Dark Knight 4 soundtrack only to find missing events from his project with a 12am deadline?! he won't be wasting time trying to get around bugs.
 
it's not rocket science to write code to import MIDI files and filters should not be applied when read the files. so I am not sure why sonar would still have this problem for such a trival FILE I/O operation!
 
it looks like various bugs crop out and never gets fixed; I notice bugs from sonar2 and it is still clear and present in sonar8 so they never bother to address these bugs....oh well!
 
thanks for all the helps u guys. I wouldn't have thought of the slip edit feature.