Jump to content
Gibson Brands Forums

dark fader

  • Content Count

  • Joined

  • Last visited

Community Reputation

2 Neutral

About dark fader

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Haven't seen that, but here are some things to try: - Try using a disk utility to test the integrity of the drive in question. It's always possible that corruption is due to the thumb drive itself. - Try recreating it (maybe using the same drive) by often deleting tracks from the active playlist while practising. - Don't delete files from playlists when you're playing live. - Never put all your eggs in one basket. Always have a backup to hand. Maybe a CD or three, maybe a Pacemaker. Even a phone (although I wouldn't want to risk the interference.) Remember that with traditional media there's a whole other deck to play with if one goes down on you. No such luxury with an all-in-one solution. When I use a Pacemaker for a gig, I have a spare one queued up and ready to play on another channel. (I also don't use rewind, as that causes the device to skip and repeat for a few seconds at a later, random point in time.) Now I'll be using one Pacemaker for backup. All systems have some foibles and nothing is crash-proof. Apart from Technics 1210s.
  2. I had two main problems with the SCS.4DJ when I bought it. - All my music was managed using a program that doesn't use MP3 tags. - Some of my music is on WAVs, which don't have tags. The data that I was missing on the SCS was mainly key and genre information, essential for categorisation. I was also concerned that there was nowhere to store information like BPM on my PC after editing it on the device - meaning BPM edits only seem to exist on the external drive. So I find myself with two databases, one on my computer (the management program) and one on the storage device for the SCS. My solution is a script which first matches the tracks in the two databases, then allows transfer of information between them. This way I can use the management program (with multiple select and edit, search, filter, sort, an inbuilt player, etc.) to build good data around my song library, then transfer it across using whatever method I like to make things easier on the SCS. (Putting key information in the genre, for example). Without messing up the MP3 tags. It works for WAVs, as I'm editing a separate database rather than file tag data. And the reverse operation (copying BPM information back to the main computer database) is just as trivial, so I don't lose my BPM edits if I re-scan. Is this of interest to anyone other than me? If so I'll make downloads of the management program available and spend some time making the scripts easier to use (and make them work on both PC and Mac.)
  3. As I thought. I was having a practice recently and I just couldn't get a tight beatmatch between tracks. Whatever I did it sounded just a little bit out - like the two kick drums weren't perfectly in time. then I noticed that key lock was on for one of the decks, so I switched it off. Immediately I had a perfect beatmatch. I don't think I'll be using key-lock at all...
  4. Thanks. I'm more interested in any reasons the developers may have for not altering BPMs directly in the database (or hints they may be able to give to stop or limit any damaging effects.) Am I storing up pain for myself at a later date by doing this? My main problem is that i use a lot of wavs (which don't hold metadata) and previously used another program for managing my MP3s (which didn't update the MP3 tags...) so hacking the database is the only way I can think to get key, BPM, genre, etc. data in to the SCS.4DJ. Fixing calculated BPMs is a bonus. I'd also love to know the full extent of what the 'bpm_type' column does, and how the cue points and beat grid start position are stored. But I understand if the devs are cagey about divulging that info.
  5. I've mentioned this elsewhere, but I looked inside the database on my memory stick and found that all the BPMs had inaccurate values. Instead of 138, I might see 137.986583663456645 or 138.0097628453246 Now we're living in an age when pretty much all electronic dance music is recorded off-line using bounced-down audio, so the BPMs are as accurate as the medium allows. And the sample rate on a standard WAV or MP3 allows a great deal of accuracy. So I find that about 99.99% of tracks are recorded at an exact BPM. Exactly 128 say, or exactly 140. This means that the BPMs in the SCS.DJ might drift out slowly over time, degrading the grid accuracy and beat matches. How to fix? It's relatively simple, but I TAKE NO RESPONSIBILITY FOR ANY DAMAGE TO DATA OR HARDWARE YOU MAY EXPERIENCE EITHER DIRECTLY OR INDIRECTLY WHEN TRYING THIS PROCEDURE. Do it at your own risk! Before you start, make a copy of the DB file in case something goes wrong. (<your drive>/SCS.4DJ_Database/Stanton_DJ_DB.db). Put the copy somewhere safe on your main drive. If you want to be even more cautious, back up the whole set of 3 SCS.4DJ folders. You never know, you may lose some cue information or something, I haven't yet worked out all the file formats. I don't care about cue points as much so I wouldn't notice. Now: 1: Get Firefox if you don't have it already. 2: Get the SQLite manager for it. Go to this link in Firefox: https://addons.mozilla.org/en-us/firefox/addon/sqlite-manager/ Click 'Add to Firefox' and follow the prompts. 3: After Firefox resets, go to the 'Tools' menu and select 'SQLite manager' 4: Go to the 'Database' menu and click 'Connect Database' 5: Find your hard drive/key in the file window and enter the SCS.4DJ_Database folder. 6: At the bottom of the file window click 'Format' and select 'All files'. 7: Double-click 'Stanton_DJ_DB.db' 8: Click the 'Execute SQL' tab. 9: Copy/paste this into the text area: update songs set bpm=round(bpm,1), bpm_tapped=round(bpm_tapped,1); 10: click 'Run SQL' And you're done. Exit the app, eject your drive and try it in the SCS.4DJ. I would be interested in hearing people's experiences. If you want to see what it's doing, click 'songs' on the left under tables just after you load the database (step 7), click 'browse and search' and look at the 'bpm' fields. Then carry out the rest of the instructions and click 'browse and search' again before you close the app (after step 10). Notice how the BPM fields have changed. If you get an error or you don't like the change, copy the old database you backed up over the top of the one you altered. (Or replace the whole set of directories if you backed them all up.) STANTON EMPLOYEES: I'm getting good results with this, personally. My grids are solid, until I use the loop feature which appears to be misaligned. But that seems to be a known bug. Can anyone think of a reason why I shouldn't be doing this?
  6. I haven't come across that at all. However, I have seen the loop slip alarmingly, like there's some off-by-one error or some overly-aggressive rounding in play somewhere. You can see the markers drift away from each other quite quickly. If I go into the database and lock the BPMs to an integer value (rather than 173.9849284840002789489 or similar as set by the device or Quickgrid) then I get a really solid lock, such that I can play two tracks (at different native BPMs, but pitch adjusted to match), leave them and they'll stay perfectly in time with each other throughout, with a locked grid to match. Also, the grid seems to stick firmly to the kicks. Could it be that simple? Just some rounding on the BPM fields and an adjustment to the loop code to make it match the grid?
  7. I've been looking in the database that contains the calculated and tapped/dialled BPMs. They all have inaccuracies, some as small as 0.00000001 BPM and some as great as 0.2 BPM. It looks like there's never any rounding applied by the software - even when values are dialled in they're never exactly on a 1 or .5. This could be at least part of the reason. Over the coming months I'll working on some programs to allow manipulation of BPMs at the database level. (Assuming that after testing my changes I find them to be stable.) Any features you'd like to see?
  8. I know what you mean, it is really hard to let go once you've put so much into something. For the record I think it's an awesome piece of kit, it just has some foibles. As have all my favourite pieces of hardware and software in the past! Would you be able to explain how the grid inaccuracy manifests itself? I'm not noticing anything wrong when I use *2 to get 170+ BPM values... Or when I edit the database file to change the bpm or bpm_tapped fields directly. On the other hand I do notice what looks like floating point rounding errors in the data, which could explain the doubled BPMs appearing as 173.99. In the database the values have a very large number of decimal places, with nothing at exactly whole or half numbers. Easily fixed with a SQL query... (By the way, what effect does the 'bpm_type' field have, apart from making the BPM blue on the device?)
  9. Ah, so it was the accuracy of the GRID LINE POSITIONS that was degraded. Now I begin to see where you're coming from. Now I've manually set a number of tracks to 17x values and the accuracy of the BPM itself seems really good - so you must be talking about the start position of the grid (as can be set by using a non snapped cue point)? That I really don't care about. It's easily set at any time if needed - a relatively quick operation, and one that comes naturally to an experienced DJ as part of a set. Setting the BPM is the soul-destroying and time-consuming part. The point being that an assumption was made (that the grid line starting position was more important than BPM entry usability) which in my case was way way off. Quite a way off given how much time I'm spending replying to this. > You can question it all you want-the results sucked. I will question it, and I'll question it more. You see, although you were striving for perfection (a laudable goal), this kind of thing comes off looking really amateurish. The consumer in this situation doesn't understand the subtle differences between the internal algorithms and just sees a nonsensical limitation. I mean, what, really, is the difference between dial in 175 and 87.5 * 2? If I get you right, nothing. But even if there is, all I know as a consumer is that it takes me ages to get to the correct value one way, and the quick way is inexplicably blocked from me. Honestly, if I'd have played with this in a shop before buying it and seen that behaviour, I'd have laughed and moved to the next device. Can you not see the UX disaster this limitation creates? Have I not made it clear in previous posts? So what's the worst that would happen, realistically, if users were allowed to dial in the value and be damned? If it uses the same algorithm as the *2 feature then it's just as 'harmful' as that feature. Which IS allowed. So why stop them getting there the quick way? If there is a problem with grid position, why not just warn the user that accuracy is degraded at high BPMs? This could be a message that pops up when the user dials in a high value, suggesting they divide by 2. Anyway, thanks for the reply. I know this isn't your fight any more.
  10. Never mind, it's just an MD5 hex digest. :) Nice and easy. Just doing some experiments with edits to the database file now...
  11. Come to think of it, this seems to be a perfect place to use a keyboard... Don't you think? :) That would magically speed up BPM entry! With short cuts to double and halve the BPM (/ and *), the up/down keys to change the BPM by +/-0.01 and page up/page down move to the next highest or lowest whole BPM... That would be a really good workflow. And it would drastically reduce wear on the digital dial. (Changing the value from 115 to 87 takes a long time and a lot of spins.) OK, I think we may be talking at cross purposes. > The 150 limit was put in by myself and Penguin. We did it because the auto-BPM algorithm needed to have a limiting range to be more accurate. This makes little sense to me. Sometimes the auto-BPM algorithm gets it right and gives me BPMs of 174/175 instead of 87 and 87.5. (This is using Quick Grid rather than the tap BPM which appears to be functionally useless for D&B, even if I tap it at half time). So the auto BPM algorithm doesn't have an upper limit that I know of. The tap BPM algorithm doesn't either. Nor does the doubling algorithm. The only thing that has an upper limit is the manual dial-in BPM, which is what slows me down and frustrates me. I mean, if the auto BPM is out by, say, 0.4, I have to: Click 'Edit BPM' Click Enter Click 'Edit BPM' Scroll to 'Dial in BPM' Spin the wheel to the correct value Click Enter Click 'Edit BPM' Scroll to 'Multiply by 2' Click Enter And THEN it leaves me at something like 173.99. That's a lot of work for a single track. I don't want to be doing that live - I have better things to do! That means I need to spend hours and hours applying this (or just the doubling, or a much longer and far more annoying process if the auto BPM value comes in at something like 115) to about 70% of my D&B tracks before I can use them. And I have a lot. Anything that speeds up this process will help me avoid attempting to pass the unit at force through a closed window. And as every part of the system seems to respect >150 BPM values apart from the manual entry, I don't see how it can possibly make anything less accurate to lift the artificial restriction! How, exactly, is accuracy being degraded? Surely, as it allows me to correct the doubling error, it makes things more accurate? Maybe the 150 restriction was removed from the auto BPM after you left, but they forgot to lift the restriction on the manual entry?
  12. That all sounds very positive. Thank you. The thread title was a joke! And may have also been put there to make the thread stand out a bit... ;>
  13. I play a lot of D&B, and I know I'm not the only SCS.4DJ owner to do so. Unfortunately I've found a few problems that slow me down when preparing my collection. - Often the BPM is calculated such that a bar actually contains 5 beats. This leads to nonsensical BPM values. (115.xx instead of 174, for example). - Often the BPM is calculated at half the correct value. (Standard, I know.) - If I try to use the tap to roughly find the BPM, I constantly get values with an error margin of roughly +/-3 BPM. This is no matter how long I spend tapping. - If I try to dial in the correct BPM I'm generally very far away from the correct value, so lots of time-consuming spinning of the controller is required to get through all the steps at 0.01 BPM accuracy. - When I get to somewhere around 150 BPM, I'm not allowed to dial any more. There is an artificial limit. - If I double a BPM, a value over 150 BPM is allowed. However, 87 BPM * 2 often calculates out to 143.99 BPM, which is visually confusing. - If I try to edit a value over 150 BPM, the value snaps down to 150 as soon as I move the control. The upshot is that I can just about fix up my collection, but it's a long and painful process. I can't use the tap function so I need to repeatedly dial in half-time BPM guesses and reset the grid with the cue, then visually check that the grid matches the kicks. Then I need to double the BPM, leaving many tracks 0.001 BPM out. This last bit I can't change. I'm guessing that D&B doesn't feature much in the testing process, which is understandable, but it is still very popular in the UK. So: Could we have a patch with an extension to the range of the dialled in BPM? Maybe with a way to change the step value to 0.5 or 1 BPM? Could someone look at the tap algorithm when used for high-BPM genres like D&B and hardcore? Could someone look at why doubling a BPM sometimes gets things wrong by 0.01 BPM? Also, if videos of the issues (and example MP3s) are required, let me know. Thanks!
  • Create New...