You never answered my question, by the way. What do you think, with all these threats of physical violence you keep making? Should I be trying to get people to report that as abuse? What would you do, if it were the other way around?

mike_mccue


I have already reported myself.

Did you take a video for proof?

John T


I've got this whole thing on film. Got all kinds of media people on the phone. It's going to be bigger than Paris Hilton's sex tape.

Surely there's a workaround until they patch it up???????

I thought you guys had each other blocked? 

Lost in this thread, I fear, was my attempt to be helpful... 
I had a major issue with my audio loops changing length, & others appear to be having the same issue.  
I did find that if you immediately correct the 'beats in clip' setting after enabling looping, the audio clips behave as desired.  Hope this helps someone else.... 

 
1)  Select your groove clip.
2)  Open the Inspector.
3)  Inspector lets you choose Clip, Track or ProCh, choose Clip
4)  Once you've chosen Clip, there are 4 submenus:  Properties, GrooveClip, AudioSnap & ClipEffects, choose GrooveClip
 
The 'beats in clip' setting is now visible.  
 
When I tried to convert an audio clip into a loop, it consistently added 4 measures (16 beats) to the length of the audio clip on my project.  When I entered the proper value here, everything started to behave as I expected.    
 
Hope this helps!

how about this...
convert a section of your virtual synth. midi to audio freeze
take that clip slip edit and move to the one.  1.1
change the view in the track view to audio transients.
open the audio snap
hit the  edit clip maps button. that brings up on the top of the clip a numbered line representing where audio snap thinks the beats fit with the audio clip.
move the first of the flags to the desired beat location. above the transient.
press set project from clip. move on down the line. and keep pressing the edit project from clip until you done. 
change the view back to audio
 grove clip loop it it may change length select it right click go to clip properties  right click on it and go to audio streching tab change the the correct amounts of beats.
metronome and meter will follow the timing even if it fluctuates. and will be represented in the tempo view.

shawnbulen


Lost in this thread, I fear, was my attempt to be helpful... 
I had a major issue with my audio loops changing length, & others appear to be having the same issue.  
I did find that if you immediately correct the 'beats in clip' setting after enabling looping, the audio clips behave as desired.  Hope this helps someone else.... 

way to go shawn!! that's what I meant when I wrote "I beat matched a song with audio snap. and It worked swimmingly."

shawnbulen


Lost in this thread, I fear, was my attempt to be helpful... 
I had a major issue with my audio loops changing length, & others appear to be having the same issue.  
I did find that if you immediately correct the 'beats in clip' setting after enabling looping, the audio clips behave as desired.  Hope this helps someone else.... 

Hi Shawn,

 Thank you for posting a suggestion that is on topic last night.

 I saw your post and responded with the reply that once you use the Set Measure/Beat at Now process that going to groove clips and changing the beats count seems to make stuff weirder than anything I showed on the video.

 I find what you are recommending very effective when I am working on a audio groove clip and there is no mystery meat data hanging outside the clip boundaries that SONAR will not delete from the track view.

 The issue I was demonstrating when I recorded the video is that

1) Set Measure/Beat at Now seems to really make a mess of the clips ability to reference the new grid.

2) Applying trimming doesn't trim the clips

3) Bounce to clips sometimes cuts off events that are beyond a slip edit at the very next measure and sometime it does.

4) One effect of Set Measure/Beat at Now's disruption of the time line sync is that SONAR seems to get confused with how it deals with clip boundaries and so sometimes the an event at __:01 is considered part of the past measure while other times it understands that the end of a clip is really supposed to be just shy of the next measures _:01 beat

5) The snap to measure settings sometimes account for this in a smart way and understand that setting a loop at say for example 1:01:001 to 5:01:001 is really meant to play back and be edited as 1:01:001 through 4:04:960 (did I get the 960 right? I always forget what that really is because for the most part SONAR understands the intent of a loop or clip edge that is snapped to a measure)

6) It seems to me as if snap to Midi extra option is related to some of this confusion. If the snap is too measure SONAR seems to remember that the convention is to say for example 5:01 when it really knows that 4:04:906? is the real boundary. It seems like adding the snap to MIDI makes SONAR really think 5:01:001 is 5:01:001. That sort of makes sense but it seems like sometimes SONAR is smart enough to interpret the context of the process and not get confused. I think this is demonstrated at minute apprx 12:30 of the video where you see the PRV has no kick when you wouldn't expect it but then after slip editing out and back to the measure that the event shows up in PRV when it's not usually shown. I think this may also be why the apply trimming isn't working at all.


It seems to me as if Set Measure/Beat at Now works with the MIDI tick resolution in such a way that when it converts the placing of each event along the new time line tempo grid that event times get some sort of round errors that must confuse SONAR.

It seems as if there must be some need to lock down the new grid and to have the event that you specifically placed at 1:01:001 and 5:01:001 stay exactly where you put them. When some of the processes I've been talking about above are attempted the positions of those specifically placed events lurch sideways along the time line and no longer sit in the relative positions.... in this example the relationship is presumably a distance of 4 measures but after sliding the clip or running some processes you can see that the distance between the two events defining the boundaries will change... which indicates to me that there is some sort relationship with the perceived timeline and SONARs internal resolution.

7) I also suspect note durations can cause lots of misunderstanding with regards to clip boundaries, but in this instance I find that realization confusing because my event list shows that I am on Channel 10 and the content is not intended to have note duration because the events are drum hits. Perhaps SONAR is hiding some duration data that it can't trim because the durations are not presented. It's possible the foot controller is a cause... but even though I did not show this in the video... I hand edited the foot controller data to make sure it was at default by the end of the clip in an effort to make sure it did not extend beyond.


The instructions for using any of the features I have found to be buggy are very clear and easy to understand... there is nothing confusing about the instructions. The bugs I presented are all encountered when using the SONAR application in a basic manner using procedures that are clearly intended to work perfectly and create a seamless session where making music is the goal.

This shouldn't require a collection of work around tricks.

best regards,
mike

Crg

1) Set Measure/Beat at Now exactly as the manual tells you too and found several bugs. 2) I Apply Trimming exactly as the manual tells you too and it doesn't do anything 3) I Bounce To Clip exactly as the manual tells you too and it leaves hidden data beyond the boundaries. 4) I attempt to make a Groove Clip exactly as the manual tells you too and it leaves hidden data beyond the boudaries. 5) I Set Selection to Loop exactly as the manual tells you too and one end of the loop disappears.

 
I don't think you were play acting Mike. You did several things in addition to the steps listed, moving the clip to a new start time and different positions, trimming, replacing the trimmed portion, etc. It seems you got confused about how many commands you had present by the time you applied groove clipping. Perhaps not, I had a hard time following all the steps you took and what the heirarchy of actions would be at that point and why you did some of them. In the case of the phantom note for instance, did it appear after you trimmed the clip as it was no longer hidden?

This is exactly what I think I observed.

After I had attempted to use the track view to annihilate everything outside the clip boundary I saw that the event at 5:01:001 persisted.

I didn't see it in PRV... and I think I should not have at that point.

Then I slipped the clip out a bit and looked in the PRV and the event was there at 5:01:001... which it should have been... but indeed I became confused because I thought I had deleted it via track view with a half dozen attempts at apply trimming or bounce to clip. When I slipped the clip edge back to 5:01:001 the event persisted in PRV and that's when I think it was truly confusing because unlike a moment prior when I was confused but SONAR was acting somewhat predictably this situation defied the convention. When I slipped the clip back edge back to the very same 5:01:001 the event persisted in PRV.

I think the subtley lies in the way the loop is labeled e.g. 5:01:001 in the loop module is really 4:04:960? but it says 5:01 because it's easier to think that way.

I also think there must be some issue with rounding errors during the Set Measure/Beat at Now. I rarely use that function and when I went to look in v8.5.2. and v8 I learned that it is very problematic in those version as well. I guess I have hed good luck in those previous versions in that I did not encounter the bug before and thought that was new to X1. I guess it's actually one of those multi year bugs that hasn't been fixed.

I also think that the Snap to Midi clips Snap function may be exasperating the issue I am trying to describe where the loop selection may say 5:01:001 but actually mean 4:01:960?. I think it is a great convenience to see the simplified numbers and that I may be causing SONAR to place the marker literally at 5:01:001 with the snap to settings where the the set loop to selection method does a bit of inaccurate simplifying in and effort to make it seem easier.

I'm still a bit confused about it all.

Thank you Craig for the straight forward commentary and the mention that you did not think I was acting in purposefully disingenuous manner.

FWIW I posted this video as a an official problem report before linking the video here. IMO it would have taken far more time to describe the situation in a written form so I prepared the video for Cakewalk and my colleagues here to review.

very best regards,
mike

spanky

mike_mccue


I have already reported myself.

Did you take a video for proof?

No. What I did is report my outburst moments after I wrote it and I ASKED Cakewalks moderators for help with a situation where a fellow forum poster has made a hobby of trying to infuriate me by repeatedly attacking my character, credibility, skill set, and work ethic rather than offer a contrary opinion supported by information pertinent to the topic at hand.

I am asking for help and hope that someone will ask John T to interact with the information in my posts rather than repeatedly test my patience with his personal attacks.

I should not have to block someone to defend my self from repeated insults.

I finally need a little help with this because I just a human and I have a limit to the amount of bull**** I can take.

very best regards,
mike

Jim, Thank you.

I feel that from my fist encounter with Mr John T his posts have been designed to ridicule.

I have clearly stated this to him and have asked him to stop with the personal attacks on several occasions.

I have a easy to review history of being able to disagree on issues with civility and I am well known to accept corrections.

I don't know what else to do but to ask for others to exert gentle influence upon my antagonist in an effort to have the personal attacks cease and desist.

I can not simply agree to disagreement in the form of personal insults.

I am trying to confine my discussions to issues but can not remain clear headed while under constant assault by someone who's agenda is apparently one of delivering personal insults at ever opportunity.

Thank you very much for attempting to interject some reason into the discussion.

very best regards,
mike



 

mike_mccue

John T


Imagine having to start "from scratch" on a four bar loop when you knew exactly how to fix it even beforehand. Oh, the agony.

More attacking the messenger.

Slime Ball.

Mike while you have toned down your constant, constant attacks in almost every positive thread here-does not mean the past all goes away. Read over "your" posts since X1 came out. Sorry, but they are "ATTACKS" on the software, the company and anyone who dared post a positive thread.
Now you are trying to tone it down. OK-That's good. That's a start. I have watched your video 5X and I have read and re-read the post from the Geek and 2 others about the process you filmed. Without really ever using the process in my work it's fairly easy to see how to avoid what happened-Yes, I know you followed the manual word for word. But, Mike, your sonar knowledge and skillset are far beyond mine and the manual-so why.............................
Reporting John T. and I guess myself is OK. Have at it. But please report yourself. I NEVER attacked CW, never went out of my way to sabatoge every positive thread because I was unhappy. I only responded "in kind" to you when you engaged in this offensive of yours against CW, X1 and anyone who posted positive experiences. It amazes me how you do your best to undermind the launch of X1 and then turnaround and accuse others of attacking you.
You use "nice words, inuendo and intellectual wit" to sugar coat your attacks.
 

rbowser


Setting beat at now?--Why?

So that the Project Tempo gets adjusted top what is being played. That is quite obvious.

I guess the manual says that, and this whole section that you were referring to should be rewritten.

No of course not. The bugs should be fixed.

Making a groove clip is a much more straight forward proposition and works when the length of the clip is correct before applying the groove.

This is true. I tend to automatically hit Bounce-To-Clips before turning anything into a groove clip but that doesn't mean that Sonar shouldn't work the other way round too. Or, if there are technical limitations to fully implementing this, Sonar should do the "apply trimming" or "bounce to clips" itself with a warning that any data outside the clip will be lost. As it stands, the implementation is either buggy or sloppy depending on how you look at it.

You seem to be arguing something truly bizarre: That it is OK that the software is implemented the way it is, that users should figure out their own workarounds and that there is something wrong with Mike for pointing out the flaws. That is pretty damned freaky if you ask me.

Mike, I basically was simply asking if your post was to be taken literally when you said you were putting together a hypothetical situation.  If you feel like you shouldn't have done that now, and you're pissed off at yourself, don't take it out on me because I can push back when I want.  Ok?

No, you are being silly. Mike demonstrates some clear bugs in Sonar. End of story. It is absolutely legitimate for Mike to get pissed off at people questioning his intentions and, as so often on this forum, completely missing the point! Mike is trying to get the software that we all use improved. He is doing us all a service. You and John T are just sabotaging a perfectly good thread. (For reasons that I, as a sane person, can not comprehend). You are doing us all a disservice.

UnderTow

I just watched the video.  I've always had unexpected results using groove-clipping since maybe Sonar 6.  Because of it, I changed my workflow and now I always compose to a metronome. If I need to loop something, I'll do it manually.  That always works out faster than trying to arm-wrestle Sonar.