i simply don’t want cubase to create a ‘set event snap point’.
how do i completely remove that function from ever happening?
i just don’t want it, no matter what the reason is.
1 Like
also, why isn’t there a shortcut keycommand option for ‘reset grid and tempo editing’ in the ‘definition’ panel in the sample editor?
You can’t remove it but you can edit where it is placed or negate its effect by disabling the Snap button. What are your reasons for not wanting it?
The snap point has a tendency to be placed at arbitrary points in a clip upon import. If you’re dragging a lot of audio files into your project it’s a pita to have to open the editor every time to drag the snap point to the start of the clip.
2 Likes
True it can get in the way. It would be helpful to have a function to automatically set the snap point to the start of selected events (it has been requested before). In the meantime you can make a macro: move the cursor to the start of the event and then Audio>Snap Point to Cursor (unfortunately one event at a time).
1 Like
the ‘set event snap point’, which is the initial marker that cubase makes (the capital S in a box shown in the screen shot i attached), isn’t arbitrary at all. it creates it after 1 second of audio is recorded.
i don’t want cubase making that ‘snap point’ because it snaps to the transport bar whenever i try to precisely copy and paste a clip to another track and it messes up the timing.
the fact that there isn’t a function to disable clips automatically snapping to the transport bar at the ‘set event snap point’ is absolutely asinine. not to mention that there isn’t a key command option for the ‘reset grid and tempo editing’, which takes the ‘set event snap point’ to the beginning of the clip.
1 Like
But can’t you simply switch off Snap (‘j’ keyboard shortcut)?
it seems like you’ve never actually had to deal with this issue. here’s the kicker: switching off snap makes no difference.
1 Like
i saw a post made 11 years ago asking for a feature to disable ‘set event snap point’.
after over a decade and hundreds of dollars in upgrades, we still don’t have an easy way to do this with multiple clips and just have to “deal with” cubase making an unsolicited ‘set event snap point’.
incredible.
Makes no difference to what? It makes a difference to how the event will be placed on the timeline, right? I mean if Snap is switched off the Snap point in the audio event is not taken into account.
I’m probably not understanding exactly what you are trying to achieve. Please explain in a step by step.
what don’t you understand? did i not make it crystal clear how copy and pasting an audio clip automatically snaps the ‘set event snap point’ to the transport bar? thus messing up the timing?
the snap on/off function has NOTHING TO DO WITH the ‘set event snap point’
it will snap automatically to the transport bar the moment you press ctrl+v of an audio clip that has that ‘snap point’ REGARDLESS OF SNAP BEING TURNED OFF
Nope.
you can’t
I do understand the frustration… and placing this apart from the tone and angst of your post above, that is a better explanation. Thank you.
You are right. That is a problem. I don’t know of a solution - as I mentioned above you can’t remove the snap point. Someone else here might know of a workaround.
1 Like
I happily duplicate tracks all day using Alt + Ctrl while dragging and have no problems with the timing getting messed up, ever. If you use Alt + Ctrl to drag duplicate OR if you use Alt + V to “Paste at Origin” then it does not matter where the “Snap Point” is because it will use the start of the event as the reference point and the timing will never be off.
As a matter of good practice I always drag the origin to a specific bar or fraction thereof which also eliminates your problem. If the origin of your event is to the right of the “Snap Point” then the snap point is ignored entirely and the start of the event is used for all snapping anyway.
And to actually answer your question: It’s the Pre-Record Setting in Preferences
The reason the snap point is “always exactly 1 second” into the clip is because the snap point is the actual point where you hit record and the default “Pre-Record” setting is 1 second. The stuff before the snap point should be stuff you weren’t even aware you recorded anyway because it should be 1 second before you even hit the button. But if you go to Edit → Preferences → Record → Audio and set “Audio Pre-Record Seconds” to 0.0000 it will effectively fix your whole problem. The snap point will become the very start of the event every time, but you’ll have no pre-recording so your punch-ins will have to be exact.
The reason you’re seeing the snap-in point like you are is because you’re punching in your recordings less than a second after hitting the record button. Most people like a little more lead-in than that so they end up moving the beginning of the event to the right and the snap-in point gets scooped up with it and they never notice your issue. Setting pre-record to 0 will effectively give you what you want but the real issue here is actually your recording technique. I really can’t figure out how you’re even accomplishing having so much audio information within 1 second of hitting the record button, you just punch in audio takes without any context? It’s either amazing or insane.
@sagebrushfire
Some of what you describe is not strictly accurate.
That’s not true in the case of dragging to duplicate an event. The snap point in the duplicated event remains at the same position as the original, so if it is not set to the start of the event then it will not be at the start of the event in the duplicate, and if the Snap button is active the snap point in the event will be used to place the event along the timeline. It will not use the start of the event.
Paste at Origin ignores the snap position but is used specifically to move an event to a single point on the timeline. It has no direct influence on snap behaviour and cannot be used as a generic way to make snapping happen according to the start of audio events.
That is not true. When dragging an event to a new position on the timeline the snap point will not be ignored and will be used for all snapping if the Snap button is active, and this regardless of the origin time of the event.
From the user manual p.616:
The event snap point is set as follows:
● If you record an audio event, the snap point is set to the next grid position.
● If you bounce a selection, the snap point is set to the start of the new event or to the first
snap point that you set manually.
● If you bounce a range selection, the snap point is set to the start of the new event or to the
first snap point that you set manually.
● If you freeze an audio event, the snap point is set to the start of the new event or to the first
snap point that you set manually.
● If you export audio, the snap point is set to the start of the new audio file.
AFAIK all of this is accurate except point 2.
Stingray,
No you are misinterpreting what I said. I wasn’t implying that the snap point moved, I was saying that the position of the moved event is unaffected by the snap point when you use Alt + V or Ctrl + Alt + Drag. The snap point can be anywhere but it doesn’t matter, the event start will stay in the same place and prevent timing issues when duplicating—thus making complaining about the snap point unnecessary.
It looks like setting pre-record time to 0.0000 seconds will solve the original “problem” here. That said the real solution is to track a little differently. Always start recordings on a grid position (Why wouldn’t you?) and always have lead-in time (again, why would you not do that? Who is recording and wants to immediately have to start less than a second after hitting the record button?)
I’ve been using Cubase for 7 years and never once even noticed or cared snap points where elsewhere besides the very start of the event. I move and duplicate tracks all the time without ever experiencing timing issues.
The screenshot provided is honestly vexing, I don’t even understand how THAT MUCH audio information could be recorded before a snap point was set.
But in the case of drag copying an event the snap point does have an effect, assuming the Snap button is active. If the snap point has been placed at an unsuitable position within the event then this may well disturb the intention of the user when moving or copying events. This can easily happen with non-musical recordings since when you record an audio event, the snap point is set to the next grid position. That grid position / snap point is unlikely be in a meaningful position within non-musical audio material. Also if the user decides to use copy / paste to paste an event, the position of the pasted event will be governed by the snap point even if the Snap button has been de-activated. In addition, holding Ctrl to disengage snapping behaviour while dragging doesn’t help here either - that merely disengages all snapping, it doesn’t engage snapping to the start of the event.
So I’ll reiterate: it would be helpful to have a function to automatically set the snap point to the start of selected events (it has been requested before).
Alt + V is irrelevant for the reasons I outlined above. Paste at Origin ignores the snap position but is used specifically to move an event to a single point on the timeline. It has no direct influence on snap behaviour and cannot be used as a generic way to make snapping happen according to the start of audio events. It doesn’t help with this issue.
Not really. Take a good look at the posts by the OP.
If the snap point has been placed at an unsuitable position within the event
Exactly, if you did something wrong to make the snap point wrong then you are wrong and really it’s your personal problem, stop being wrong.
There are 2 ways to have the snap point be automatically placed somewhere that’s not the start of the event:
- Have pre-record enabled and make use of it by dragging your event start to the left.
- Have your cursor in a random, non-grid-aligned starting position before you hit the “Record” button.
The first is a feature but I don’t recommend it, it’s hyper-situational. I only suggested changing it because Croove’s screenshot shows a lot of audio data before the snap point and pre-record is the only way I can imagine that happened.
The second one is just user error. Either start your recordings with the cursor on a grid position or move the start of your event to the right with snapping on and it will scoop up the snap point for you and position it on the grid.
What you two don’t seem to get is that the current behavior specifically prevents the timing from getting messed up. The snap point has to be a grid position or it makes no sense. If your event started off grid but you sang or played to the metronome, resetting your snap point to the start of the event will actually screw up your time. Having it automatically choose the nearest grid line allows you to copy/paste in other locations without the timing getting messed up.
OP thinks that the snap position is messing up their timing but the reality is that they aren’t using the timing tools properly and they’re creating more work for themselves. If they would just use the event snap point the way it’s intended, their whole experience would actually be a lot less stressful.
When Recording Audio in Cubase:
- Give yourself a bar or a few beats of lead time (silence) for each take.
- Snap your cursor to a grid position before hitting record.
- Drag your event start to the right and snap it to a grid location if you forgot to do #2.
Do that and you will never have copy/paste drama and your snap points will always be the starts of the events. Cubase 14 also has slip editing so there is just no real reason not to snap the starts/ends of your events to the grid because you can slip edit the actual audio if you want off-grid adjustments.
Once again, this is misinformation. Did you read the manual? Did you read my posts? The first case of how a snap point is set is as follows:
The event snap point is set as follows:
● If you record an audio event, the snap point is set to the next grid position.
This is from page 616 of the manual.
Another way that snap points will be written not at the start of an event is when using render in place.
You are correct that the snap points are there to help and they do indeed prevent the timing getting messed up in many circumstances. I totally get this and am totally familiar with snap points and how they help the user. I personally am certainly not against snapping and snap points in general and I’ve never tried to suggest otherwise.
But what you don’t seem to get is that there are occasions when the snap point works against what the user is attempting to do, and this is what this topic is about!!! It’s not about what is right with snap points (or what you think is right about snap points). It’s about one user’s experience in one particular situation. And not even once have you addressed that specific situation. This is more than a little tiresome and TBH a waste of time.