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, ...]

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).
  
  
  
 

Cactus Music


Me too, made it to second part and even though it's fairly well written it suffers from a lack of editing out 80% of content which is mostly opinions. 

First my friend you wasted your time posting in the old forum, if you are an X series user there is a much more active forum for you.
But your issue is universal to all the versions. Sonar PG changes can be viewed in the events list. Sometimes they do not show, this in a way is not so much a bug but overlooked peiece of program language. My solution is to slip edit the start of a track to the first note and the hidden PG event will not be triggered. 
I will also open the midi file in Cubase where those random PG events that do not show in Sonar will show.  

I decided against posting in X series since this is sonar8, not X series and there must be huge difference in the code base. maybe old bugs are fixed, while newer ones crop up?!!
 
also I use Slip Editing exclusivly using Audio tracks, where I may want to adjust the audio offset relative to the measure grid interval.
u seem to imply with slip editing, those hidden msgs can 'magically appear' in the clip pane, well even I enable PRV mode I see the blocks of notes in the gridline of the CLIP pane , but none of the PCG msgs show up, remember: I had manually delete PCG msgs fro my track to isolate the problem!!
 
say a 4 bar clip starts from measure 191 and ends at measure 195 (4th beat in 4/4 time);
 
the HACK FIX I did is this:
 
1. cut entire clip from measure 191 to 195 inclusive, copy them to another temp region.
2. paste the temp region clip in the same original region (which is suppose to be blank event free).
 
presto --> problem solved. sonar8 does not send that CC msg this seems to work. kinda dumb that I have to do this task for each clip!
 
if I have to slip edit or do a cut/pasto operation everytime I encounter this problem, then the workflow is compromised.
 
 
 
 

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

I like Dan's hypothesis above. I've had the experience of accidentally disabling a patch change by muting a clip. However, this theory doesn't explain why the patch changes are random. Or was the word "random" incorrect? Maybe you meant "unexpected, but one of the patches programmed into the track"?

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.
 
 
 

bitflipper


I like Dan's hypothesis above. I've had the experience of accidentally disabling a patch change by muting a clip. However, this theory doesn't explain why the patch changes are random. Or was the word "random" incorrect? Maybe you meant "unexpected, but one of the patches programmed into the track"?

yes sometimes that is a common mistake; you accidently mute the clip or had muted it, but forget to unmute it. if it was only that trivial a culprit I would not posting this msg.
 
yes - u are right: not random as I thought, but one of the patches programmed at same point in time after the Big Bang, and before the last time I insert the last PCG change msg.
 
so the precise bug is: sonar8 sends a roque, unwarranted pcg change msg and the peculiar patch # in this rogue msg = some patch I did insert a long time ago at one point in this project but it seems to 'remember' this patch (even though I have deleted this event from the event list editor).
 
 
 
 

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. 

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

hey Dan, I finally figure it out - looks like the slip edit mucked up my sequences. as I said I don't really slip edit my MIDI clips, but what happened is that I trim my MIDI clips and the SONAR TRIM feature cuts off the clip to start from first note to last note.
 
THIS DESIGN logic could be a bug? I mean what if I insert a series of controller CC change like a crescendo or pcg change before the start of clip. it looks like when sonar8 trim the clip: it only considers note events, not cc events hence the bug! I think this is a design logic bug.
 
it is due to this inadvertinent slip edited sequence that I did not see the hidden cc msg being implanted there.
 
==> another nasty suprise: u don't see the events if clip is slip edits; very inconvenient!
 
==> so where is the old pcg change coming from? it appears to have been left in there when I CLONE a MIDI track, and even if I mute the CLONED track (cloned tracked for caching/reference) it appears to affect the new clip in that it is stuck in there!!
 
Event Editor should show every event on the track, regardless of your slip edited clips whether you slide them left/right.
 
once I drag my clip backwards, I am scrolling back a few measure whoa I see some cc msgs that aren't suppose to be there.
 
issue is resolved: I can fix it but it is a pain in the butt the way sonar8 logic works.
 
also listend to your soundcloud recordings - very nice and melodic, reminds me of Bjorn Lynn music.
 
I hear lots of TRITON program sound in your recordings...
 
 
 

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.