andy-chiles
groovindj wrote :
I'm assuming it could be scripted (load browsed song to deck 99 or whatever's required) so it works all the time.
Locodog?
Locodog?
But wouldn't this mean that the songpos gets loaded just as on a regular deck?
So that it fills up from 0 to 100% ?
If this is the case I think the whole idea of comparing the waveforms quickly would not get fulfilled, because there is too less difference to a regular loading command and the upcoming waiting period.
This would be great to see the cues and stuff, but the comparison of the tracks structure is as difficult as on a regular deck...
If the waveform could be instantly visible somehow, then the 'deck 99 idea' is the perfect solution.
P.s.:
If you give me some time till my gigs are finished during this weekend, I could make you some screenshots and some little tests which I could post here, to give some ideas.
Posted Sat 24 Aug 19 @ 8:19 pm
Nicotux
Using the 6 deck variation of the default skin I scripted something like that :
- it was initialy used for the "cover in the browser" using deck 42
repeat_start getwav ? repeat_stop getwav : repeat_start getwav 10ms & get_browsed_selection_index 255 & var_equal brsp ? nothing : set brsp `get_browsed_selection_index 255` & deck 5 load
with a skin mod for the display stuffs it may be a start point
- it was initialy used for the "cover in the browser" using deck 42
repeat_start getwav ? repeat_stop getwav : repeat_start getwav 10ms & get_browsed_selection_index 255 & var_equal brsp ? nothing : set brsp `get_browsed_selection_index 255` & deck 5 load
with a skin mod for the display stuffs it may be a start point
Posted Sat 24 Aug 19 @ 8:58 pm
groovindj
andy-chiles wrote :
But wouldn't this mean that the songpos gets loaded just as on a regular deck?
But wouldn't this mean that the songpos gets loaded just as on a regular deck?
Well yes of course - but that's all we have. Nothing currently exists to display waveforms in the browser.
As I said before, if something was implemented, it's sure to slow down at least the browser. You think loading one waveform is slow, but you want waveforms for every track in the browser to appear instantly?
Why do you think VDJ draws the waveform when the track is loaded to a deck? Imagine the space required if it were to store waveform images for every track. Then what happens if you add or delete a cue point? VDJ has to write that image again?
Posted Sat 24 Aug 19 @ 9:52 pm
locoDog
A second thumb nail and dev modifications to cover art space is the most reasonable way, but cost/benefit, I'm not really caring for this idea
Posted Sat 24 Aug 19 @ 10:20 pm
Nicotux
if it were to store waveform images for every track it would not use as much as cover because images might be smaller
- currently 192MB for 8364 files in cache ... for a collection of 2910 files taking 80.2 GB ...
192M/8364 average 24K per cover gives extra 66M additionnal space used for waveform with the same size ?
adding or deleting a cue point, the image may already be in memory, saving it would not hurt
still problems with hotcues... can ignore them
the info pannel seems a good idea too as there is some space on top of the rating stars or within position and track ha already be loaded
but yes it takes some time to load - would slow not really
- currently 192MB for 8364 files in cache ... for a collection of 2910 files taking 80.2 GB ...
192M/8364 average 24K per cover gives extra 66M additionnal space used for waveform with the same size ?
adding or deleting a cue point, the image may already be in memory, saving it would not hurt
still problems with hotcues... can ignore them
the info pannel seems a good idea too as there is some space on top of the rating stars or within position and track ha already be loaded
but yes it takes some time to load - would slow not really
Posted Sat 24 Aug 19 @ 10:39 pm
andy-chiles
Please don't misunderstand me... I know this will consume some resources.
Therefore my thoughts were something like a snapshot (similar to the cover in filesize) of the waveform itself would do the "instant-displaying"-job.
The image of the waveform doesn't change during the whole existence of the track.
Then we only have to think about what to do with the cues, as they aren't contained in the snapshot of the waveform.
But I think loading a small image and reading/overlaying cues from the database would speed this whole thing up, instead of drawing a whole waveform everytime or snapping a new image everytime a cue gets changed. In fact this is what rekordbox seems to do. (Please also take a closer look at the behaviour of rekordbox -> depending the waveform in the browser when changing cues, and how everything looks before and after scanning a track).
And if this whole thing gets placed inside the info panel, or maybe even combined with the prelisten-player, then the browser wouldn't have to load a lot of cues and pics at once and the amount of CPU usage could be kept low enough because it's done for each song individually.
If this feature (or the prelisten-player) is hidden, even more cpu gets saved.
Therefore my thoughts were something like a snapshot (similar to the cover in filesize) of the waveform itself would do the "instant-displaying"-job.
The image of the waveform doesn't change during the whole existence of the track.
Then we only have to think about what to do with the cues, as they aren't contained in the snapshot of the waveform.
But I think loading a small image and reading/overlaying cues from the database would speed this whole thing up, instead of drawing a whole waveform everytime or snapping a new image everytime a cue gets changed. In fact this is what rekordbox seems to do. (Please also take a closer look at the behaviour of rekordbox -> depending the waveform in the browser when changing cues, and how everything looks before and after scanning a track).
And if this whole thing gets placed inside the info panel, or maybe even combined with the prelisten-player, then the browser wouldn't have to load a lot of cues and pics at once and the amount of CPU usage could be kept low enough because it's done for each song individually.
If this feature (or the prelisten-player) is hidden, even more cpu gets saved.
Posted Sat 24 Aug 19 @ 11:38 pm
the SOUND INSURGENT
andy-chiles wrote :
I think it should be clear for everyone that djing is not only about mixing...
Preparation is key!
And having an overview which tracks are prepared, which may need preparation, or the difference between track versions is a reeeeealy huuuuge advantage.
I didn't knew either what the waveform in RBDJ should be good for, till I started using it extensively.
Try it yourself and start to prepare tracks for a specific event in a totally empty rekordbox, then you get the point very quickly. It's a big timesaver because you have an overview. A really big timesaver!
And if this fits in someone's workflow, why don't implement it?
I find it unneccessary to discuss about whether or not implementing something that a view people like, just because it doesn't fit in some others workflow.
If you get rid of the waveform in rekordbox, then you can do the same in Virtual DJ.
But the once who see the point and get a use out of it, will love the software even more.
And the use of such a waveform was written in the first post.
Preparation is key!
And having an overview which tracks are prepared, which may need preparation, or the difference between track versions is a reeeeealy huuuuge advantage.
I didn't knew either what the waveform in RBDJ should be good for, till I started using it extensively.
Try it yourself and start to prepare tracks for a specific event in a totally empty rekordbox, then you get the point very quickly. It's a big timesaver because you have an overview. A really big timesaver!
And if this fits in someone's workflow, why don't implement it?
I find it unneccessary to discuss about whether or not implementing something that a view people like, just because it doesn't fit in some others workflow.
If you get rid of the waveform in rekordbox, then you can do the same in Virtual DJ.
But the once who see the point and get a use out of it, will love the software even more.
And the use of such a waveform was written in the first post.
I see what your saying but still doesn’t make sense to me and I’ll use your example.....
OK I do prepare tracks for sets but here’s the thing, doesn’t matter if they have cue points or not because sometimes I don’t always use the same key points on the same song every single time I use that track, so therefore it is always going to change. The mix is not always going to sound the same, the cue points aren’t always going to be in the same place.
But it doesn’t really matter to me and you clearly don’t see my point in having you try to explain why it’s such a great idea.
And I think if it gets added it should be in the info pane with the rest of the tracks info and yeah, let us be able to edit the different fields from there as well.
I’m done with this thread.....
Posted Mon 26 Aug 19 @ 1:13 am
andy-chiles
the SOUND INSURGENT wrote :
I see what your saying but still doesn’t make sense to me and I’ll use your example.....
OK I do prepare tracks for sets but here’s the thing, doesn’t matter if they have cue points or not because ........
andy-chiles wrote :
I think it should be clear for everyone that djing is not only about mixing...
Preparation is key!
.............
Preparation is key!
.............
I see what your saying but still doesn’t make sense to me and I’ll use your example.....
OK I do prepare tracks for sets but here’s the thing, doesn’t matter if they have cue points or not because ........
I'm trying to follow your explanation, but I don't get why the cues should change that often.
I personally set my cue points when I'm preparing a song. Maybe I change one or two of them later, but the most cue points I've set will stay at the same point where they have been set.
I don't delete the most of them at any time or don't change them fundamentally for any reason, if they are set correctly.
And by 'correctly' I mean to set the cues on the beginning of distinctive points of the song... such as the chorus, verse, break, drop, hook and so on.
This points don't move somewhere else or don't get changed by any matter...
So maybe you work different with cue points, but as far as I know they are meant for the way I explained, and then the idea makes sense, because you can see how your preparation of the track went so far.
Posted Mon 26 Aug 19 @ 1:45 am
groovindj
andy-chiles wrote :
they are meant for the way I explained
There are no hard and fast rules. People can use cue points however they want to use them.
Clearly TSI uses them differently to you. I am different again - I have very few tracks with cue points.
Your usage is probably the most common, but it's not "meant to be" that way.
Posted Mon 26 Aug 19 @ 7:19 am
andy-chiles
groovindj wrote :
There are no hard and fast rules. People can use cue points however they want to use them.
Clearly TSI uses them differently to you. I am different again - I have very few tracks with cue points.
Your usage is probably the most common, but it's not "meant to be" that way.
andy-chiles wrote :
they are meant for the way I explained
There are no hard and fast rules. People can use cue points however they want to use them.
Clearly TSI uses them differently to you. I am different again - I have very few tracks with cue points.
Your usage is probably the most common, but it's not "meant to be" that way.
I do not doubt his way of using the cue points, or any other way...
You probably said it right or better than me: That the way I explained is more common.
But thats why the idea is also more "legit" or better said: It probably will reach more peoples needs, who use cue points the common way.
Posted Mon 26 Aug 19 @ 11:39 am
NingDynasty
This is a really cool discussion and for me one of the ways I like to use the RBDJ browser track preview is to quickly click on a tracks drop to get a short audio preview to check if it has the feel for what I'm looking to play next.
I guess the biggest issue is RBDJ probably uses the waveform view function that they use in the sampler where with VDJ we'd have to use many more resources because we'd have to load all the functionality of a full deck.
I guess the biggest issue is RBDJ probably uses the waveform view function that they use in the sampler where with VDJ we'd have to use many more resources because we'd have to load all the functionality of a full deck.
Posted Mon 18 May 20 @ 8:13 pm
gvaste
I think this could be awesome, having a quick view of the structure of the songs can be useful if you use them wisely on your workflow.
and this being optional doesn't harm other users that don't need them.
and this being optional doesn't harm other users that don't need them.
Posted Thu 28 May 20 @ 1:38 pm