Connexion rapide:  

Forum: VirtualDJ Technical Support

Sujet Pitchlock turns itself off since b5180 - Page: 1

Cette partie de ce topic est ancien et peut contenir des informations obselètes ou incorrectes

Hi!

I wondered why Pitchlock always turns itself off when I start VDJ or when I load a new track.
I searched for some setting related to pitchlock, but didn't found anything.
Then I started downgrading backwards the early access builds:

b5181 has this bug...
b5180 has this bug too...
b5095 doens't have it.

Took a look in the changelog...
In b5180 there was a change:
-beatlock doesn't interfere while loop smaller than 1 beat is active or stutter cue is held
Maybe it has somehing to do with that.
 

Posté Fri 26 Jul 19 @ 7:55 am
Looks like there is a new config setting - autoPitchLock - not documented in the manual, or the wiki, or even in VDJ internally.

What it's supposed to do exactly is therefore a mystery.

I think it's a good thing for pitch lock to be off when VDJ starts, or reset when a track is loaded. It's much safer, and a better default.
 

Posté Fri 26 Jul 19 @ 8:40 am
I saw that setting...
But I couldn't make out a change as I switched it on and off...
That's why I downgraded, because I like to leave it turned on :)
 

Posté Fri 26 Jul 19 @ 8:44 am
Maybe this is another thing that should be added to deck_set :-)
 

Posté Fri 26 Jul 19 @ 8:53 am
groovindj wrote :
Maybe this is another thing that should be added to deck_set :-)


:D
 

Posté Fri 26 Jul 19 @ 9:11 am
AdionPRO InfinityCTOMember since 2006
pitch lock will always turn off if the bpm is not matched on the new track

Using auto pitch lock, pitch lock will activate as soon as bpm are matched, and deactivate otherwise, so this is the most convenient way to keep it on when it makes sense, and disabled otherwise.
 

Posté Fri 26 Jul 19 @ 9:27 am
I experimented a little bit with it...

Seems like autoPitchLock activates the PitchLock as soon as the decks get synced (via the software)...
Means that it has to be synced with the smart_play, beatlock or another syncing command, but not when its done manually...

I definitely like the idea, but at first I think I would prefer both options... A permament pitchlock and an automated one.
 

Posté Fri 26 Jul 19 @ 9:30 am
Adion wrote :
pitch lock will always turn off if the bpm is not matched on the new track

Using auto pitch lock, pitch lock will activate as soon as bpm are matched, and deactivate otherwise, so this is the most convenient way to keep it on when it makes sense, and disabled otherwise.


Ok you posted while I was typing :)

Yes I think this is a very good solution...
I don't know how it will feel to work with it, but I like the whole idea...
(Maybe I could imagine a small adjustment: If the decks get synced manually it could turn on as well)

Do I have to remap anything from PitchLock to autoPitchLock?


(Aaaaaaand I posted some behaviours of the programm which I noticed, could you take a look at my recent posts if you havent yet) :)
 

Posté Fri 26 Jul 19 @ 9:36 am
AdionPRO InfinityCTOMember since 2006
Yes, there's an action auto_pitch_lock to enabled/disable the autoPitchLock feature.
I'd say try it for a while and see what you think.
 

Posté Fri 26 Jul 19 @ 9:44 am
Yaaaaaap, I'll try it and if I have some ideas I'll let you know.
But as far as I tried it yet, I think I could work with it pretty well :)
 

Posté Fri 26 Jul 19 @ 10:14 am
Maybe I have an idea... or rather: I think I made out what confuses from time to time regading the auto_pitch_lock.

Currently there are two ways to choose from:
1. auto_pitch_lock on = pitchlock off till some syncing is happening, then pitchlock on.
2. auto_pitch_lock off = no pitchlock at all.

What confuses (/ concernes) me about that:
If I have auto_pitch_lock turned OFF, I have no chance to lock the pitch-faders permanently over several songs,
it will turn off every time a song gets loaded.
But this is confusing because I don't want any automation if auto_pitch_lock is OFF.

For my understanding it would be more logical if auto_pitch_lock is more like an really good assistence, BUT...
If I turn auto_pitch_lock OFF, I would still like to be able to turn pitch_lock on and leave it as that...
Instead of having to turn it back on again, because an *turned off* automation turned pitch_lock off.

Long story short: Keep pitchlock as it was, but 'override' its behaviour when auto_pitch_lock is on.
 

Posté Fri 26 Jul 19 @ 11:04 am
AdionPRO InfinityCTOMember since 2006
I'm pretty sure pitch_lock turned off before as well after loading the next song unless autoBPMMatch was on. I don't see why you'd want the new song to be pitch locked at some random speed.
 

Posté Fri 26 Jul 19 @ 11:18 am
Adion wrote :
I'm pretty sure pitch_lock turned off before as well after loading the next song unless autoBPMMatch was on. I don't see why you'd want the new song to be pitch locked at some random speed.


Mostly I have smart_play and pitch_lock on at the same time...
But sometimes (during transitions or mashups and stuff) I have to re-coordinate the settings of them, for manual syncing purposes (e.g. on Timecode) but still pitch_locked movement via a external controller.

The only thing what is really confusing is that it turns off during auto_pitch_lock is off...
Because this is also a kind of an automation if it happens by itself.
But thats why I turn the automation off, because I want to leave it at my choosen state.
 

Posté Fri 26 Jul 19 @ 11:23 am
djkrysrPRO InfinityMember since 2010
To add to the confusion.

With auto_pitch_lock OFF, If i set up a track with smart_play ON and pitch_lock ON, when I hit the play on the track, VDJ turns pitch_lock OFF.
I discovered this to my misfortune when DJing live to a packed club the other night and doing what I always do, playing a track at 120, new track is 125bmp, so hit play, tracks sync perfectly, then during the mix hit pitch_reset on the track to take speed up to it's speed, only when I hit pitch_reset it all went horribly wrong and I couldn't understand why. After the second time this happened, and I knew I hadn't hit the wrong buttons, I experimented and discovered what was happening.

So I concur
IF auto_pitch_lock is OFF, STOP MESSING AROUND PLEASE.
I applause the constant improvement to Virtual DJ but you need to appreciate people use this live in a working environment and if you are going to change the way the program behaves, it should be made extremely clear when this happens so we are all totally aware, and it should NOT be the default behavior where possible.
 

Posté Sat 10 Aug 19 @ 12:34 pm
djkrysrPRO InfinityMember since 2010
Also, on the "deck options" button, you have removed the options to toggle "smart_cue", "smart_loop" and "master_tempo" and you have replaced them with the "auto" options, again, can we have both for people who want to do it the other way and of course for ease of access with master_tempo & smart_cue
 

Posté Sat 10 Aug 19 @ 12:43 pm
They've not been removed. They're just accessed from other menus now.
 

Posté Sat 10 Aug 19 @ 12:47 pm
djkrysr wrote :
To add to the confusion.

With auto_pitch_lock OFF, If i set up a track with smart_play ON and pitch_lock ON, when I hit the play on the track, VDJ turns pitch_lock OFF.


Yes, this is what I say all the time!
If the automation is off, please let pitch_lock ON if it was manually set ON.
Don't turn it OFF automatically, because the automation was disabled before!
Turning it OFF is an automation that shouldn't be done because automation was OFF!
 

Posté Sat 10 Aug 19 @ 12:50 pm
djkrysrPRO InfinityMember since 2010
groovindj wrote :
They've not been removed. They're just accessed from other menus now.

They have been "removed" from the place they were, the place I knew they were, now I have to go looking for where they are now because it's all undocumented.
I was not at the meeting when VDJ programmers decided to move things, if you don't tell us about it, how am I supposed to know.
Please, I don't understand how YOU don't understand the problem, I'm working in a busy club, trying to do my job and it's all changed and i'm working in a busy club, I can't just stop and go post on a message board for advice!


 

Posté Sat 10 Aug 19 @ 1:06 pm
Well, the first thing I'd say in reply to that is - why are you using a brand new untested (by you) build in a live environment?

Any updates you install should done when you're not working. When you have time to check them over to make sure everything works reliably and as expected.

TBH I'd say it's your fault for putting that build on your gig computer before you were familiar with it.
 

Posté Sat 10 Aug 19 @ 1:12 pm
The newest public build is 5186.
The changes were made in 5180.
There were 4 EarlyAccess Updates between the first change and the final build. (5180, 5181, 5182, 5185)

In NO SINGLE CHANGELOG was ONE SINGLE WORD about THIS CHANGES.
So your argument is not valid.
Because even at the final release of the version containing this changes was no word written about the changes, and also not during the change-process.


I'm not meaning to offend you, but you didn't know either about the changes (see the posts above).
How could we know about this then?
There has to be more transparency and some consese about the changes, how users could imagine to work with it.
Just changing behaviours is not cool, even if it seems logical. We showed that there are unlogical thinkings in it, so please hear us!
 

Posté Sat 10 Aug 19 @ 1:23 pm
61%