Hi everybody,
I like to use foobar for my part-time amateur DJ-ing purposes. foobar is not a DJ-ing software, but I'm used to it and don't need any complicated features (mixing, syncing...). I just make playlists and play them, with the "skip silence" DSP feature activated. It works nicely.
There is however one feature that I'm really missing. I'm currently using foo_dsp_soundtouch to make small tempo changes in some of my songs (only tempo changes - I'm not interested in pitch changes or speed changes). foo_dsp_soundtouch works fine with foobar 1.x, but :
- It seems its development has been stopped,
- I haven't found a way to contact its author (Acropolis),
- He seems to have been banned from Hydrogenaudio anyway.
So I guess that sooner or later
a new tempo change component for foobar would be welcome.
Unfortunately I'm not a developer myself, so I'd like to suggest right from the start some simple features that I'm missing. I hope they will seem of interest to a willing developer and that they'll be taken into consideration. Thank you.
A. TEMPO CHANGE MODES :The tempo change component would function according to 4 user-selectable modes (
Modes 1 and 2 are already provided by foo_dsp_soundtouch) :
Mode 1 : OFF => no tempo change
Mode 2 : STANDARD => adjust a TEMPO ALTERATION slider (e.g. from -100% to +100%), and the tempo changes in real time without pitch alteration
e.g. +100% means that tempo would go up from 70 to 140
e.g. -100% means that tempo would go down from 140 to 70
Starting from any tempo change component that would provide Modes 1 and 2 (e.g. foo_dsp_soundtouch), implementing Modes 3 and 4 would be quite easy IMHO : I've written down almost everything that would need to be coded.
Mode 3 : TARGET BPM :[blockquote]0. (This mode needs songs to have been previously tagged with
%bpm% (e.g. using foo_bpm, e.g. %bpm% = 114) and
%target bpm% (e.g. %target bpm% = 120))
1. Play a song
2.
IF [%bpm% tag is empty
OR %target bpm% is empty
OR %bpm% = %target bpm%
],
THEN do nothing
3.
IF %bpm% < %target bpm%,
THEN set TEMPO ALTERATION to (%target bpm% / %bpm%) - 1 (accelerate tempo to %target bpm%)
4.
IF %bpm% > %target bpm%,
THEN set TEMPO ALTERATION to (%bpm% / %target bpm%) - 1 (reduce tempo to %target bpm%)
5. Change tempo like in Mode 2[/blockquote]
Mode 4 : BETWEEN MIN BPM AND MAX BPM :[blockquote]0. (This mode needs songs to have been previously tagged with
%bpm% (e.g. using foo_bpm))
1. Set MIN BPM and MAX BPM in the component preferences dialog (e.g. 80 and 120)
2. Play a song
3.
IF [%bpm% tag is empty
OR if MIN BPM <= %bpm% <= MAX BPM
],
THEN do nothing
4.
IF %bpm% < MIN BPM,
THEN set TEMPO ALTERATION to (MIN BPM / %bpm%) - 1 (accelerate tempo to MIN BPM)
5.
IF %bpm% > MAX BPM,
THEN set TEMPO ALTERATION to (%bpm% / MAX BPM) - 1 (reduce tempo to MAX BPM)
6. Change tempo like in Mode 2[/blockquote]
B. INTERFACE REQUEST :It would be nice if the component UI would be available as a DUI element (if feasible), rather than having to go each time through the preferences to adjust the slider like we currently need to do with foo_dsp_soundtouch.
C. OTHER COMPONENT SPECS :Component UI :- The component UI would be minimalistic, with only A TEMPO ALTERATION slider
- A right-click onto the UI would display a Mode selection menu (Modes 1, 2, 3 or 4)
-> In Modes 1, 3 and 4 the TEMPO ALTERATION slider would be inactive/greyed (these are automated modes with no user interaction)
-> In Mode 2 the TEMPO ALTERATION slider could be adjusted in real-time by the user
Component preferences dialog :- Choose tempo change mode (e.g.via radio buttons)
-> Mode 1 : nothing to set
-> Mode 2 : enter TEMPO ALTERATION (the UI slider would react once "OK" button is pressed)
-> Mode 3 : nothing to set
-> Mode 4 : enter MIN BPM and MAX BPM - Set TEMPO ALTERATION slider behaviour, according to two modes :
-> Integer values only : -2%, -1%, 0, +1%, +2%, etc.
-> Continuous values : -0.02%, -0.01%, 0, +0.01%, +0.02%, etc. - Set UI orientation (vertical or horizontal slider)
I hope a developer will be interested in making this become real. I would really appreciate, and I hope other users will appreciate too.
Thanks in advance.
A small correction, sorry :
Mode 3 : TARGET BPM :
[blockquote]4. IF %bpm% > %target bpm%, THEN set TEMPO ALTERATION to 1 - (%bpm% / %target bpm%) (reduce tempo to %target bpm%)[/blockquote]Mode 4 : BETWEEN MIN BPM AND MAX BPM :
[blockquote]5. IF %bpm% > MAX BPM, THEN set TEMPO ALTERATION to 1 - (%bpm% / MAX BPM) (reduce tempo to MAX BPM)[/blockquote]
Some practical examples :
%bpm% = 100; %target bpm% = 110
=> TEMPO ALTERATION = 0.1 = 10%
%bpm% = 100; %target bpm% = 90
=> TEMPO ALTERATION = -0.1111 = -11.11%
%bpm% = 70; MIN BPM = 80; MAX BPM = 120
=> TEMPO ALTERATION = 0.1429 = 14.29%
%bpm% = 130; MIN BPM = 80; MAX BPM = 120
=> TEMPO ALTERATION = -0.0833 = -8.33%
These are just examples. I guess in real world it is advised to keep TEMPO ALTERATION somewhere between -10% and 10% in order to limit sound artifacts.
What do you mean by tempo changes? You wrote that you are not interrested in pitch-changes - however, if the component should be relatively simple to make, it would involve changes in pitch (similar to the pitch control on a turntable). This way, it's only a matter of a few simple calculations to adjust the samplerate. It could probably even just rely on the built in PPHS converter to be in the DSP chain, to ensure consistent samplerate output (and high quality conversion).
However, if you expect the pitch to be unchanged, it's quite complicated. The easiest way is probably to rely on some soundtouch-like library, but I don't know of any free ones of high quality. Also i'm not even a dev myself...
Hi odyssey. As you certainly know, Soundtouch relies on 3 different algorithms :
- "Tempo adjust" : tempo variation without pitch variation
- "Pitch adjust" : pitch variation without tempo variation
- "Rate adjust" : tempo variation with pitch variation, somewhat equivalent to samplerate variation
I'd be interested only in "tempo adjust" (sorry if I wasn't clear enough). So yes,
I expect the pitch to remain unchanged so the altered song remains as close as possible to the original.
I agree the algorithms for "tempo adjust" are more complicated than a simple samplerate variation. However I guess some of these algorithms must be well-known nowadays and even
available as open-source. For instance Audacity (open-source software) implements such algorithm in its "Effects" menu ("Change tempo"), which (unless I'm wrong) means the algorithm itself must be accessible to a developer.
I've used Audacity's algorithm quite a number of times, and quality seems very good to me. For the record I'm not expecting miracles from a "hi-fi" point of view : only a decent "tempo adjust" feature which, combined to the 4 user modes that I've tried to describe to the best of my knowledge, would greatly enhance my (unpaid, voluntary) work as an amateur DJ, and make a lot of people happy (e.g. the dancers).
FWIW, Audacity's source code is available here : http://audacity.sourceforge.net/download/beta_source (http://audacity.sourceforge.net/download/beta_source)
I hope it helps.
GPLed code cannot be legally used in foobar2000 components. Audacity is GPL.
The source of a GPL component using GPL libraries could be released, but it wouldn't make said component any more legal. The typical scenario with using GPL libraries has been mostly favorable, with the developers of said libraries being satisfied with their use and the component source being released, enough to not request removal, but the license does not require them to be so friendly.
There have been other projects in the past where developers have been less friendly. For instance, a Winamp3 component based on UADE was discontinued and removed from publication by request of the UADE developers. The author of libsamplerate, or Secret Rabbit Code, also asked that nobody make a foobar2000 component without paying his exorbitant commercial licensing fee, went and made a component of his own at some point, then ceased updating it with his newest version of the resampler library and/or newer versions of the foobar2000 SDK. Mudlord was also asked by the developers of the STSound package to remove his foo_input_ym component from publication, which he did at one point, but then changed his mind, so now they are within their rights to sic the FSF on him and any other site which is still providing it for download.
Audacity's algorithm is not suitable for realtime tempo change. It seems to use SoundTouch, so decent quality is out of the question.
SoX is too, since it uses the same shit.
Thanks for all your replies.
From what I understand :
- Audacity's "tempo change" GPL library (or any similar algorithm under GPL license) could be used in a foobar2000 component, if "the developers of said libraries being satisfied with their use and the component source being released, enough to not request removal". So I guess asking the relevant developers first would be a good start, with a reasonable chance of success (thanks kode54).
- Audacity's "tempo change" GPL library (or any similar algorithm) is suitable for Modes 3 and 4 (the two modes that Soundtouch doesn't provide), since these two modes aren't real time : the tempo change is made before the song starts playing, according to its tags, and there is no real time modification afterwards. For the record, Audacity's tempo change takes about half a second for a regular mp3 or FLAC, with my modest Core i3.
mudlord, do you seem to think that Audacity, Soundtouch or SoX do not offer "decent quality" ? IMHO Audacity and Soundtouch offer more than decent quality for my purposes, so that wouldn't be a problem.
Besides, first things first : I guess priority #1 in coding such component would be to make it work. Eventually improving sound quality (improving the algorithm itself) could only be less prioritary. Don't you think so ?
EDIT : for the record, SoX uses both a simple algorithm and a WSOLA (Waveform-similarity-based Synchronized OverLap-Add) algorithm for changing tempo (see here : http://sox.sourceforge.net/Docs/Features (http://sox.sourceforge.net/Docs/Features) ). Here's some info about the WSOLA algorithm :
- Wiki : http://en.wikipedia.org/wiki/Audio_timesca...ion#Time_domain (http://en.wikipedia.org/wiki/Audio_timescale-pitch_modification#Time_domain)
- A Sourceproject page for a WSOLA algorithm : http://sourceforge.net/projects/mffmtimescale/ (http://sourceforge.net/projects/mffmtimescale/)
- The algorithm developer (flatmax) : http://sourceforge.net/users/flatmax (http://sourceforge.net/users/flatmax)
- His web site : http://flatmax.users.sourceforge.net/ (http://flatmax.users.sourceforge.net/)
- Another WSOLA implementation by flatmax : http://sourceforge.net/projects/mffmvectorwsola/ (http://sourceforge.net/projects/mffmvectorwsola/)
I think the old school tempo change where the pitch is also affected should also be considered when someone picks this up.
When there are only slight tempo changes suitable for beat matching possible tempo change artifacts are producing much worse sound than the small change in pitch.
BTW it's a bit off topic but for dj-ing like interface two more features would be usefull:
1) ability to manipulate the bass eq on the fly (just a simple slider),
2) ability to manipulate the volume (this is already possible)
As a bonus it would be great if these sliders could be adjusted using global shortcuts.
E.G. I know beats don't match I can bend the tempo/pitch slider slightly to sync it the same way I would do while using real turntables without looking at the screen.
IMHO Audacity and Soundtouch offer more than decent quality for my purposes, so that wouldn't be a problem.
You obviously have NOT tried extremely large time scaling factors >_>
Like...I dunno, days and weeks?
Not to mention the
documented issues other users here made in regards to SoundTouch's quality?
Besides, first things first : I guess priority #1 in coding such component would be to make it work. Eventually improving sound quality (improving the algorithm itself) could only be less prioritary. Don't you think so ?
No, because when it comes to FB2K and GPL, they don't mix. AT ALL. History has proven that.For the record, Audacity's tempo change takes about half a second for a regular mp3 or FLAC, with my modest Core i3.
*facepalm*
I am sure every user would want to wait a extra few seconds just so they can play a song. And have the component require a i3 as a minimum. And for good performance, require a quad Xeon server. >_>
I checked those links. Thank you for insulting my intelligence on what time-scaling is. I was thinking of implementing tempo scaling for foo_dsp_effect, but oh yeah! SoundTouch is horrid for long scaling factors! And everything else I seen is GPL! I don't need more legal threats, don't you agree?!
Why be so aggressive ? My previous post wasn't even aimed at you. I don't understand, so please calm down at once. Thank you.
You obviously have NOT tried extremely large time scaling factors >_>
Did you read my previous comment where I said "I guess in real world it is advised to keep TEMPO ALTERATION somewhere
between -10% and 10% in order to limit sound artifacts" ?
Besides, I'm afraid your comments about sound quality won't be of any help. If you have a better algorithm you are welcome to share it. If not, I think the known algorithms are much better than nothing at all.
And I'm going to repeat myself : I'm quite happy with Audacity and Soundtouch's quality as long as we remain in the -10%/+10% zone. Please remember I'm talking about DJ-ing purposes, not about "hi-fi" in a quiet living-room.
when it comes to FB2K and GPL, they don't mix. AT ALL. History has proven that.
We are not talking about fb2k itself but about a 3rd party plugin that would be created by a 3rd party developer. So I guess it will be up to him/her to take appropriate decisions, including "asking the relevant GPL developers first" in order to allow a fair use of their algorithm(s). But again, if you have a better solution you are welcome to share it.
I am sure every user would want to wait a extra few seconds just so they can play a song. And have the component require a i3 as a minimum. And for good performance, require a quad Xeon server. >_>
There must be a misunderstanding here. What's the purpose of all your irony ? I'm not a native english speaker so I probably don't understand.
I checked those links. Thank you for insulting my intelligence on what time-scaling is
Like I said, my previous post wasn't aimed at you. Why did you have to feel insulted ? And what's wrong about me giving some valid links for all other people who don't know exactly what time-scaling is ? You do remember this is a public forum, right ?
I was thinking of implementing tempo scaling for foo_dsp_effect, but oh yeah! SoundTouch is horrid for long scaling factors! And everything else I seen is GPL! I don't need more legal threats, don't you agree?!
You seem to envision a very particular use of time scaling. I guess most people would use it reasonably (i.e. between -10% and +10%). What would be the purpose of those "long scaling factors" you are talking about ?
I'm just giving some info, that's all. There's no reason to feel offended by that, don't you agree ?
Again, please calm down so this discussion can remain constructive. Thank you.
Did you read my previous comment where I said "I guess in real world it is advised to keep TEMPO ALTERATION somewhere between -10% and 10% in order to limit sound artifacts" ?
Which is horseshit and you know it. What about users that want MORE control? Have you ever considered that components ARE NOT tailormade to PRECISE requirements?
Please remember I'm talking about DJ-ing purposes, not about "hi-fi" in a quiet living-room.
Then go get someone to make a DJ component!
but about a 3rd party plugin that would be created by a 3rd party developer.
And I was talking about GPL, FB2K AND 3rd party components. Thank you for fucking avoiding kode54's comments about libraries + components.
What's the purpose of all your irony ?
No end user will stand for waiting for something to process AND then playing a song.
THEY WANT IT AT LEAST in realtime. Or not at all.If you have some *magical* idea of making a NON realtime algorithm REALTIME, then I would love to hear it. I wouldnt mind complete technical explanations, as to how you will optimize a square to fit in a round hole.
You do remember this is a public forum, right ?
Noooo?
Again, please calm down so this discussion can remain constructive. Thank you.
No, because your idea of reusing GPL code in NON GPL COMPONENTS IS RETARDED. From a legal perspective.
Seriously, go fuck yourself with a rake. I wasted enough time explaining which WOULD go towards a new pitch/tempo feature.
wcs13,
do not care about mudlords aggressions, when it comes to gpl he becomes neurotic because of earlier experiences.
(is that an argument for or against something? no, but true)
Thank you q-stankovic. I guess I'll be ignoring mudlord's comments from now on, and I'd appreciate if he'd leave this topic which is obviously useless for him (although I can't force him to do so).
In order to go on constructively, here are some comments (that have nothing to do with mudlord) :
- The component's TEMPO ALTERATION capabilities could be similar to those of Soundtouch (-100% to +100%), which would allow users to do what they want with it. I'd still advise to remain in the -10%/+10% domain, but everyone will be able to do what he/she wants, right ?
- As for real-time, I wouldn't mind waiting for half a second, or a second, or even more, between two songs. Seamless playback is nice, but in this case I simply don't care. In case someone wants to know how a DJ like me can wait several seconds between two songs, I'll be glad to provide further explanation.
- BTW, I don't know if a foobar component can know in advance the next song to be played, because in that case everything could be processed in the background, providing seamless playback.
I have also made a simple diagram of what the component could look like. Please, don't bother telling me that it's obvious and that everyone on earth knows everything about it already. I'm just trying to make myself
perfectly clear about my suggestions (which remain of course suggestions), that's all. So I'd appreciate if my modest efforts were acknowledged instead of being criticized and insulted.
Thank you all.
(http://img215.imageshack.us/img215/8047/64378528.jpg)
@wcs13
That looks interesting. Awaiting the first release of your component!
Thank you Sandrine. Like I said, unfortunately I don't have any dev abilities :
Unfortunately I'm not a developer myself, so I'd like to suggest right from the start some simple features that I'm missing. I hope they will seem of interest to a willing developer and that they'll be taken into consideration. Thank you.
So a dev's help will be required sooner or later. I hope somebody will find this topic interesting enough to spare some of his/her time.
I think it's worth it, but if more people like you and me post their interest in this topic, it may help motivate a dev, who knows.
Some more links for future reference :
- SoundTouch library : http://www.surina.net/soundtouch/ (http://www.surina.net/soundtouch/)
- PaceMaker plugin for WinAmp (similar to foo_dsp_soundtouch but actively developed apparently) : http://www.surina.net/pacemaker/ (http://www.surina.net/pacemaker/)
The man behind that work is Olli Parviainen.
The SoundTouch library is
LGPL (but of course everyone knows it already), so it would help developing a new, enhanced successor for foo_dsp_soundtouch without any license problems if someone wants to pick this project up. I'm not asking for more.
Like I said, unfortunately I don't have any dev abilities
Maybe I've been too subtle before. Having a general idea for a program isn't worth anything if you don't know how to put it in code. Diagrams can't replace math formulas. Flowcharts do not make a program. DJ skills do not make you a programming project leader.
Apparently they do. >_>
Makes me wonder why the person has never requested a full DJ component. Makes more sense then some arbitrary pitch/tempo component based off some crap library........
Sandrine, you act like you know everything about my life. Well, learn this :
- I have been a project leader IRL, I have managed dev teams more than once, and I know a bit about diagrams and flowcharts (do you ?)
- However, I don't think anybody here cares about my IRL experience, so let's just put it aside. (*)
- Did I ever say I intended/wanted to be the leader of this precise project ? NO. If anyone wishes to become this project's leader I'll be only too happy.
- And did I say "I'm just giving some info, that's all" ? YES.
So, can you explain to us all what's wrong about simply giving away some info ? I'm all ears.
I kindly remind you that you are not forced to read me and that you too can leave this topic if you wish too. If you choose to stay in this topic, it's probably because in the end you think there's something interesting about it. Otherwise why would you still be here ?
(*) For the record I have done a bit of programming in the past, so YES, I can tell you that a program often begins with diagrams. But unfortunately I don't know a word about C++ (which is mandatory for fb2k components) and my programming experience is far behind me now (back in the 80's with Turbo Pascal (http://en.wikipedia.org/wiki/Turbo_pascal)). So unfortunately I'm unable to carry on this project. Well, go on, blame for that. And while you're at it, blame everyone on earth whose horrible sin is to have ideas and express them. Only developers should be allowed to have ideas, right ?Oh, and don't forget to add this one to your list : criticizing and ironizing do not make your comments any more relevant or interesting. So far your contribution to this topic has been more or less equal to
zero, while mine has been so far the backbone of this topic. So I'll put it in your own terms : "awaiting your first interesting contribution!". And no hard feelings...
Back to the interesting stuff now :I have contacted flatmax. I have told him about this project, showed him the diagram, and he has kindly replied me the following :
That is a great use of the time scale modification.
Wow! It seems that there are actually people who find my idea interesting. Who'd have believed that ?
And this also :
I have a new version of this algorithm which I will release soon ... stay tuned
But of course you brilliant minds already knew about it, didn't you ?
To be constructive, for a FB2K component, its best he uses a LGPL based license, or better.
LGPL based components have no legal issues. Pure GPL ones do.
#define BUFFER_SIZE 2048
class dsp_tutorial_nopreset : public dsp_impl_base
{
SoundTouch * p_soundtouch;
int m_rate, m_ch, m_ch_mask;
pfc::array_t<soundtouch::SAMPLETYPE>samplebuf;
unsigned buffered;
private:
void insert_chunks()
{
uint samples = p_soundtouch->numSamples();
if (!samples) return;
samplebuf.grow_size(BUFFER_SIZE * m_ch);
soundtouch::SAMPLETYPE * src = samplebuf.get_ptr();
do
{
samples = p_soundtouch->receiveSamples(src, BUFFER_SIZE);
if (samples > 0)
{
audio_chunk * chunk = insert_chunk(samples * m_ch);
chunk->set_data_32(src, samples, m_ch, m_rate);
}
}
while (samples != 0);
}
public:
dsp_tutorial_nopreset() {
m_rate = 0;
m_ch = 0;
m_ch_mask = 0;
p_soundtouch=0;
buffered=0;
}
~dsp_tutorial_nopreset(){
if (p_soundtouch) delete p_soundtouch;
}
// Every DSP type is identified by a GUID.
static GUID g_get_guid() {
// Create these with guidgen.exe.
// {A7FBA855-56D4-46AC-8116-8B2A8DF2FB34}
static const GUID guid =
{ 0xa7fba855, 0x56d4, 0x46ac, { 0x81, 0x16, 0x8b, 0x2a, 0x8d, 0xf2, 0xfb, 0x34 } };
return guid;
}
// We also need a name, so the user can identify the DSP.
// The name we use here does not describe what the DSP does,
// so it would be a bad name. We can excuse this, because it
// doesn't do anything useful anyway.
static void g_get_name(pfc::string_base & p_out) {
p_out = "Pitch Shift";
}
virtual void on_endoftrack(abort_callback & p_abort) {
// This method is called when a track ends.
// We need to do the same thing as flush(), so we just call it.
}
virtual void on_endofplayback(abort_callback & p_abort) {
// This method is called on end of playback instead of flush().
// We need to do the same thing as flush(), so we just call it.
if (p_soundtouch)
{
insert_chunks();
if (buffered)
{
p_soundtouch->putSamples(samplebuf.get_ptr(), buffered);
buffered = 0;
}
p_soundtouch->flush();
insert_chunks();
delete p_soundtouch;
p_soundtouch = 0;
}
}
// The framework feeds input to our DSP using this method.
// Each chunk contains a number of samples with the same
// stream characteristics, i.e. same sample rate, channel count
// and channel configuration.
virtual bool on_chunk(audio_chunk * chunk, abort_callback & p_abort) {
t_size sample_count = chunk->get_sample_count();
audio_sample * src = chunk->get_data();
if (p_soundtouch && (m_ch != chunk->get_channels() || m_rate != chunk->get_srate()))
{
p_soundtouch->flush();
insert_chunks();
delete p_soundtouch;
p_soundtouch=0;
}
if ( chunk->get_srate() != m_rate || chunk->get_channels() != m_ch || chunk->get_channel_config() != m_ch_mask )
{
m_rate = chunk->get_srate();
m_ch = chunk->get_channels();
m_ch_mask = chunk->get_channel_config();
p_soundtouch = new SoundTouch;
if (!p_soundtouch) return 0;
p_soundtouch->setSampleRate(m_rate);
p_soundtouch->setChannels(m_ch);
p_soundtouch->setPitchSemiTones((float)12.0f);
p_soundtouch->setSetting(SETTING_USE_AA_FILTER,1);
p_soundtouch->setSetting(SETTING_AA_FILTER_LENGTH,128);
p_soundtouch->setSetting(SETTING_USE_QUICKSEEK,0);
}
soundtouch::SAMPLETYPE * dst;
samplebuf.grow_size(BUFFER_SIZE * m_ch);
while (sample_count)
{
unsigned todo = BUFFER_SIZE - buffered;
if (todo > sample_count) todo = sample_count;
dst = samplebuf.get_ptr() + buffered * m_ch;
for (unsigned i = 0, j = todo * m_ch; i < j; i++)
{
*dst++ = (soundtouch::SAMPLETYPE) (*src++);
}
sample_count -= todo;
buffered += todo;
if (buffered == BUFFER_SIZE)
{
p_soundtouch->putSamples(samplebuf.get_ptr(), buffered);
buffered = 0;
insert_chunks();
}
}
return true;
}
virtual void flush() {
if (p_soundtouch)
{
p_soundtouch->clear();
}
}
virtual double get_latency() {
return (p_soundtouch && m_rate) ? ((double)(p_soundtouch->numSamples() + buffered) / (double)m_rate) : 0;
}
virtual bool need_track_change_mark() {
// Return true if you need to know exactly when a new track starts.
// Beware that this may break gapless playback, as at least all the
// DSPs before yours have to be flushed.
// To picture this, consider the case of a reverb DSP which outputs
// the sum of the input signal and a delayed copy of the input signal.
// In the case of a single track:
// Input signal: 01234567
// Delayed signal: 01234567
// For two consecutive tracks with the same stream characteristics:
// Input signal: 01234567abcdefgh
// Delayed signal: 01234567abcdefgh
// If the DSP chain contains a DSP that requires a track change mark,
// the chain will be flushed between the two tracks:
// Input signal: 01234567 abcdefgh
// Delayed signal: 01234567 abcdefgh
return false;
}
};
// We need a service factory to make the DSP known to the system.
// DSPs use special service factories that implement a static dsp_entry
// that provides information about the DSP. The static methods in our
// DSP class our used to provide the implementation of this entry class.
// The entry is used to instantiate an instance of our DSP when it is needed.
// We use the "nopreset" version of the DSP factory which blanks out
// preset support.
// Note that there can be multiple instances of a DSP which are used in
// different threads.
static dsp_factory_nopreset_t<dsp_tutorial_nopreset> foo_dsp_tutorial_nopreset;
Don't fucking bother me. Again.
[sarcasm]Wow ! I'm impressed ![/sarcasm]
And can somebody please take the time to explain to everyone here (including future topic readers) what exactly is that small piece of code ?
Because from what I understand it has something to do with controlling Soundtouch, but it's definitely NOT the whole tempo-change component we're talking about (I don't see any modes, any preferences or any UI).
So before thanking mudlord for his contribution and for his splendid knowledge of the "f*ck" verb and all of its variations (which I didn't know was even tolerated in HA forums), I'd like to know what we're talking about. Thank you.
And can somebody please take the time to explain to everyone here (including future topic readers) what exactly is that small piece of code ?
I think mudlord's point is, why don't you do it yourself. You said you once did some programming in Turbo Pascal so the concept is not new to you, only C++. Yeah, C++ is a bitch but there are lots of resources available, especially example code in the SDK and this forum. You can download the student version of Microsoft C++ for free.
I'm an assembly language programmer from way back. From time to time I tried to learn C++ from a book but I never got past "Hello world." So, I studied the various sample plugins and tutorials and experimented. While I still don't know C++, I've managed to write several successful foobar plugins.
I see. Thank you j_b. I'm happy that you managed, by experimentation / trial & error / etc. to write some plugins for foobar, even if it certainly took you a fair amount of time.
My point is as follows :
- I've opened this topic only to discuss in a constructive way about a hypothetic new tempo-change component for foobar, and to suggest some features which I modestly think could be useful. Nothing more.
- I didn't open this topic to tell everybody "hey, I'm about to write a new tempo-change component". I never said that, because I never had that pretention.
- I didn't this topic either to be criticized and insulted by people like mudlord, who by his insulting words (e.g. "go fuck yourself with a rake") deserves no less than my despise (even if he was the greatest dev on Earth, which I'm pretty sure he's not)
Let's be realistic here : I'm no developer and my day work
PLUS my DJ work by night
PLUS more volunteer, unpaid work (about 4-5 evenings a week !) don't really leave me time for learning a new object-oriented language like C++
AND for learning how to write a specific foobar component
AND for learning how to connect it to foobar's DSP Manager. For me it would be literally
dozens of hours which no guarantee at all to get something that works in the end.
Don't get me wrong : it's not that I wouldn't like to write a plugin for foobar. I wish I could, and I've even visited some sites before opening this topic (like Yirkha's site about fb2k component writing)... but unfortunately I can't. I'm just being realistic. Not to mention that my first component would definitely be a useless piece of crap that everyone here could cricicize.
I've never forced anyone to write such tempo-change component. Heck, I've never even really
asked for it directly (I've only made suggestions
in case someone would be interested, that's all).
I'm only a man of perfectly good faith, who thinks that he has contributed in a constructive way to this topic (e.g. because nobody had thought of the above-mentioned features before). I don't see any reason why I should be insulted by people like mudlord or criticized ironically by people like Sandrine. If this would be a forum where a member couldn't express a mere suggestion, then I'd be definitely out of here. But I believe this forum is a nice place, only polluted by some mudlord-like members.
BTW j_b, if you believe that my modest work in this topic is worth more than nothing, and if you believe that this component is worth existing, why couldn't you write it ? Like I said, starting from the existing Soundtouch library which already provides all the sound-processing features we need, I guess it would be really easy for someone who has already written several successful foobar plugins. I leave it up to you : like I said I've never wanted to force anybody.
One last thought : a forum, by its very nature, is a place where people come
help each other towards a common goal. It's
not a place where people tell other people "do it yourself". Don't you all think so ?
[sarcasm]Wow ! I'm impressed ![/sarcasm]
And can somebody please take the time to explain to everyone here (including future topic readers) what exactly is that small piece of code ?
It is a port of some old code that does exactly what you describe in your post: a means of interfacing Soundtouch with the foobar2000 audio player. A means of doing exactly what you wanted.
BTW j_b, if you believe that my modest work in this topic is worth more than nothing, and if you believe that this component is worth existing, why couldn't you write it ?
If you don’t have time in your busy life to write a plugin that meets your needs, what makes you think I do?
You’ve already invested considerable time documenting, in great detail, how this plugin, that someone else writes, is supposed to work. With just a little more time and effort, you could add a UI to the code mudlord provided. Then you could share your work to the foobar community.
As I see it, this forum is for individuals who write plugins,
that meet their needs and interests, share them with others foobar users. It’s not a place where you present the specifications for a plugin, that meets your needs and interests, and expect someone else to write it for you.
As I recall, there are winamp plugins that change pitch and tempo. There is also a foobar plugin that loads and runs winamp plugins. That should be all you need.
It’s not a place where you present the specifications for a plugin, that meets your needs and interests, and expect someone else to write it for you.
Indeed, its not a place where blueprints are made, and basically order someone to make said thing EXACTLY to your specifications.
Unless its for payment, but then this is not the place for contract work.
They can be considered, yes, but generally plugin requests are just that. Requests for a idea, not complete and utter specifications on how exactly a author must program the component in the first place.
and yes wcs13, I did a large number of foobar2000 DSP components. foo_dsp_effect is a collection of a varied bunch of them.
And yeh, that code does need a bit of work even for the filter end, but it should provide the basics: the means to interface with the library. The buffering code needs more work though.
That said, I am interested in a up to date component, just something which does not fit your exact needs.
If you don’t have time in your busy life to write a plugin that meets your needs, what makes you think I do?
I never said I thought you'd have time. I was just
asking if you would. If you don't have time or if you simply don't want to, then no problem, just forget about it.
With just a little more time and effort, you could add a UI to the code mudlord provided. Then you could share your work to the foobar community.
I don't even know where to begin, and I barely understand a word about that piece of code. Please don't say "a little more time and effort" because
it would be a huge lie. It would be "a little more time and effort" for any dev who has already written at least one working fb2k component (you or any other dev). But for me it would be litterally
dozens of hours, and you know it. You can't seriously expect me to do so. So once and for all, let's not waste any more time in this matter.
There's no way I'm writing this fb2k component, not because I wouldn't want to, but because I'm totally unable to do it. Understand it or not, but it's a fact and it won't change. End of discussion.
As I see it, this forum is for individuals who write plugins, that meet their needs and interests, share them with others foobar users. It’s not a place where you present the specifications for a plugin, that meets your needs and interests, and expect someone else to write it for you.
No one is forced to followed the specifications that I've written. Do I have to say all over again that these are only suggestions ?
Besides, when the individuals you are talking about share their creations with other foobar users, there are always
feature requests. And quite often they are taken into account,
even if they don't fit the needs and interests of the original developer. And it's a good thing, because feature request sometimes greatly improve the original components. Because devs are like other people : they can't think about everything, and sometimes they are happy and even thankful because of a nice feature request. That's how things work in foobar forums, and it's also a fact.
Well, I'm just doing the exact same thing : initially I was about to make a feature request for foo_dsp_soundtouch to its developer, period. But like I said, its developer has been banned from HA forums, and I don't know a way to contact him. I even thought of finding foo_dsp_soundtouch's source code and trying to modify it to fit my needs, but AFAIK the code is not available either (is it ?).
As I recall, there are winamp plugins that change pitch and tempo. There is also a foobar plugin that loads and runs winamp plugins. That should be all you need.
AFAIK, the only foobar component that I know and that runs Winamp plugins is foo_vis_schpeck (http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Components_0.9/Shpeck_%28foo_vis_shpeck%29), and it does only run visualization plugins, not DSP plugins. Could you please tell me what foobar component you are talking about ? Thank you.
For the record, yes, Winamp has an equivalent for foo_dsp_soundtouch. It's called PaceMaker and it's here : http://www.surina.net/pacemaker (http://www.surina.net/pacemaker) . But it does exactly the same as foo_dsp_soundtouch with no added features that I could use. And yes, I have made a feature request to its developer already. He hasn't replied to my email.
As you can see, I tried almost everything else before opening this topic. Does it seem understandable to all of you, or do I have to make myself even more clear ?
I don't think I have ever seen such disrespect in the foobar2000 forums.
You have ignored the aspects of possible licensing issues.
A dev has even provided you a great piece of source code. Hell, if this component means so much to you, why the fuck don't you JUST TRY, JUST ONCE, JUST EVEN CONSIDER TRYING (!!!!!!) to compile it?!?!?!?!?
Even I would save that code and try compile it, as I could probably extract and modify it to do what I proposed in my first post - Just to try to make a foobar2000 component. And all I've ever coded was PHP and shellscripting...
(But to be honest, I have hard figuring why you need this as a foobar2000 component - There are so many DJ'ing apps available that does what you want)
I didn't mean to be disrespecful to anybody, and if somebody feels that I have, then he/she has all my apologies because it never was my intention.
On the other hand, some people here (not you odyssey) have been clearly disrespectful to me, from the beginning of this topic, and I haven't received any apologies from them.
There are words to prove it, even insults that I had never read in a forum before. Such words haven't been moderated yet, and I wonder why.
Regarding licensing issues, I haven't ignored them at all. I have contacted the WSOLA dev to ask for his permission, and I have also contacted the Soundtouch dev. What more could I have done ?
Regarding the "great" piece of source code, it appears that it's practically the same piece of code which is freely available from foosion's site (DSP tutorial component : http://foosion.foobar2000.org/components/?...p;version=1.0.2 (http://foosion.foobar2000.org/components/?id=dsptut&version=1.0.2) ). Download it, compare both files and you'll see that mudlord hasn't done anything special here.
One last question : do you know of a single DJ'ing app which is capable of doing what I want, i.e. reading file tags (e.g. %bpm% and %target bpm%) and doing the time-stretch accordingly ? Because I don't know of any app capable of doing that. You seem to know odyssey, so please, tell me, because if I had known of a single app capable of that, then I wouldn't even have considered opening this topic.
Thank you.
Regarding the "great" piece of source code, it appears that it's practically the same piece of code which is freely available from foosion's site (DSP tutorial component : http://foosion.foobar2000.org/components/?...p;version=1.0.2 (http://foosion.foobar2000.org/components/?id=dsptut&version=1.0.2) ). Download it, compare both files and you'll see that mudlord hasn't done anything special here.
can you demonstrate your claim?
with diff perhaps?
Download the archive and see for yourself. The archive contains a foo_dsp_tutorial folder, which contains a foo_dsp_tutorial.cpp file, which can be visualized with any text editor.
Like I said, mudlord's file is directly derived from foo_dsp_tutorial.cpp (want proof ? all the original commented lines have been kept). I'm sure mudlord won't deny that.
So yes, there has been a little work done because both files aren't strictly identical (like I said they are "practically identical"). And I'm not questioning the fact that a little work has been done (but no work specific to this topic IMO : mudlord probably had that code already since he has done some work on DSP components and he has already messed around with soundtouch, so he probably did a simple Copy/Paste of his code into this topic ).
I'm just telling odyssey that this can't be considered 100% mudlord's work (he has only changed/added some lines from foosion's tutorial base), and that this can't be considered a "great" piece of source code.
That's all.
a-ha, you don't know how to code, but you are expert in judging other people work in that same code, and seeing dsp_tutorial in class name was enough for you to claim non-sense; but then you are offended if someone talks a bit hard on you
shish, you even disrespect hand that feeds you
Everyone (and I mean everyone) is able to compare two text files and see the differences. I've compared them line by line before writing my reply to oddysey. Do the same if you are not convinced.
You are talking without even having compared the files yourself. I won't discuss anymore of this matter with you until you do.
foosion's dsp_tutorial is great template and it serves purpose fine as starting point
you shouldn't look if comments match but what code does
hope you wasted your time as you wasted all other's here
you approach is wrong imo
foosion's dsp_tutorial is great template and it serves purpose fine as starting point
Yes it is. Yes it does (I guess).
you shouldn't look if comments match but what code does
I've compared them line by line
it appears that it's practically the same piece of code
yes, there has been a little work done because both files aren't strictly identical (like I said they are "practically identical"). And I'm not questioning the fact that a little work has been done
AFAIK, the only foobar component that I know and that runs Winamp plugins is foo_vis_schpeck, and it does only run visualization plugins, not DSP plugins. Could you please tell me what foobar component you are talking about ? Thank you.
foo_dsp_winamp.dll loads and runs winamp dsp plugins.
Regarding the "great" piece of source code, it appears that it's practically the same piece of code which is freely available from foosion's site (DSP tutorial component : http://foosion.foobar2000.org/components/?...p;version=1.0.2 (http://foosion.foobar2000.org/components/?...p;version=1.0.2) ). Download it, compare both files and you'll see that mudlord hasn't done anything special here.
Doesn't that tell you something? All foobar dsp plugins share the same framework and the only difference between a plugin that changes the sample rate and a one that changes the tempo are a few function calls to the appropriate external library routines in the right places. The same goes for the UI. That's how a C++ illiterate like me can write a dsp plugin at all.
People here have been trying to help you help yourself, but you won't accept any of it.
Yes...All DSP components derive from the same class, so same public methods are exposed >_>.
Resampler components I think use a different API, but thats not the point....
Yes...All DSP components derive from the same class, so same public methods are exposed >_>.
Resampler components I think use a different API, but thats not the point....
I don't know. I get lost when you start throwing C++ terms around like, derived class and public methods. The first foobar plugin I wrote is similar to your dsp_effect: It manipulates the samples in many different ways, including changing the sample rate, all within the same framework (my terminology.) Perhaps the resampler-specific API is something new. I haven't looked at the most recent SDK.
foo_dsp_winamp.dll loads and runs winamp dsp plugins.
Thank you j_b.
Unfortunately there's not yet a Winamp plugin that does what I want. But maybe one day there will be. Who knows.
Maybe even one day a dev will pick up this project and make a fb2k component, not for me, but simply bebause it's a
good idea. Who knows.
And maybe that day someone will
finally give a little credit to my idea. Who knows.
One last question : do you know of a single DJ'ing app which is capable of doing what I want, i.e. reading file tags (e.g. %bpm% and %target bpm%) and doing the time-stretch accordingly ? Because I don't know of any app capable of doing that. You seem to know odyssey, so please, tell me, because if I had known of a single app capable of that, then I wouldn't even have considered opening this topic.
This essential question remains unanswered...
For the record, here's another time-stretching / pitch-shifting library : Rubber Band ( http://www.breakfastquay.com/rubberband/ (http://www.breakfastquay.com/rubberband/) ).
It is similar to SoundTouch.
But yes, it's also under GPL license...
I am no developer but I do DJ..
I think you comment summs it up the best "part-time amateur DJ-ing purposes".
Foobar is a music player and not DJ software, I suggest you look elsewhere to DJ even though what you are wanting to do is make playlists and have the software do the mixing for you. Whilst no DJ software does everything you want (thats because there is an asumption the DJ is actually active in the process and not passive which is what your functionality would provide).
Look into Traktor and it's sync / auto mix functionality, you should really look more into DJ'ing and less into specificying requirements for a component which will never get made.. check out djtechtools which is a great site for digital DJ'ing, it sovers a plethora of technologies and software available...
You can still do all of your playlist maintenence in Foobar and just import the playlists in the DJ software...
Thanks 4nt1.
I have already tried Traktor and Virtual DJ. Their real-time time-stretching algorithms are really efficient (quite superior to Soundtouch). No glitches and no artifacts at all, even if we move the slider up and down very fast. And two performance levels are proposed (depending on your CPU). But yes, none of them proposes to automate the tempo change based on file tags, which is what I'd like.
Because yes, I'm a passive DJ because the parties where I work do not require an active DJ. I play songs, couples dance to them, and that's all. No need for effects, beat-matching and all that DJ-stuff. All I need is to keep all played songs in a 80-120 BPM range. Hence the modes 3 & 4 that I have suggested.
If there were a single software that would propose such automation, I could of course do all my playlist maintenance in foobar and import the playlists. All that I need is to find such software... or a willing dev capable of thinking about something more than his own navel. I'm sure there must be.
or a willing dev capable of thinking about something more than his own navel. I'm sure there must be.
Could you not simply type a response without an unneeded childish dig? I believe you have offered plenty of information on what you want. Any dev interested in the subject and willing to volunteer time will surely be able to find this thread.
Oh they already did..... (http://www.hydrogenaudio.org/forums/index.php?showtopic=88336&pid=753800&st=0&#entry753800)
If people are gonna act like brats...too bad....
Just quoting here, I'm too well-educated to say such things :
Seriously, go fuck yourself with a rake.
Now, you are just wasting time. Good luck with your quest.
(http://stashbox.org/1107460/there.JPG)
Indeed, when the requester starts being all childish, all bests are off.....>_>
Too bad.
I've just this week found foobar2000 as I have a requirement for an audio player with which I can adjust the tempo of ballroom dance music for practice purposes and FooBar, with the Effects DSP (thank you Mudlord), provides what I need. However, for me, it would be easier to use if the Tempo Shift control were on the user interface (like the volume control) and not buried in the Preferences (better still if it could be automated as WCS13 suggests). So while investigating if this was possible I chanced upon this thread.
I couldn't believe the treatment that WSC13 has received. It's slightly off topic but I didn't start it and something needs to be said. His suggestion was stated politely and clearly. I don't see any reason for knocking him and certainly NO reason for profanities or personal abuse.
It's silly to expect every end user who comes up with a requirement to become a developer. WCS was simply stating a requirement he had and asking if there was anyone out there who might be interested in the challenge. I see no harm in that at all. Indeed the challenge developers usually have is getting a decent specification out of their users. If the request is impossible or very complicated then that's all that needs to be said.
I've done some coding in the past, in REXX, VBA and Perl; you'll note they're all interpreted languages. So far I've not been able to get to grips with the mysteries and mechanics of libraries, compiling, linking, ddl Vs exe and now licensing seems to be another minefield to fall foul of. I'd love to be able to spend hours learning how its done but I have a day job (IT Networking) as well as my family, Cisco studies and other hobbies. I'm sure many are the same. It means I'm even more grateful (and often donate) to those who spend considerable time writing quality products for the freeware and opensource environments. It hadn't occurred to me though that those intelligent and altruistic enough to contribute to this project could abuse their users so vociferously.
WCS: I'm not sure why you got the response you did, I think its shameful and frankly embarrassing. I thought forums like this were for discussion and mutual support. I can't commit to providing a solution, but I too would find your suggestion very useful. I'll continue my investigations, my fear is I'll get hooked enough to delay my studies (again - procrastination rules!). I'll let you know if I make any progress. Feel free to contact me. If anybody would like to offer advice that might help me progress faster I'd be grateful.
BTW - I don't have a garden ("yard" in American!) so I'm afraid I don't possess a rake.
I'm not sure of the interface for DSPs to use UI Elements is public.
Although, the EQ uses such a method apparently....O.o
What annoyed me about wcs13 is that at the end of the day, the developer considers the idea, its their option to work out how to best implement said functionality. Developers here ain't drafted into coding for people for free. Unless there is some payment, then realistically, there is nothing wrong with mandating exact specs. But demanding the world for free? People need to be realistic.
Thanks Mudlord
It's a shame the discussion went off the rails. I didn't read it that WCS13 was demanding anything, just stating what would suit his requirements, and as it happens mine too. No matter, lets move on now.
I appreciate your comments about the UI and DSP components. I can see that my learning curve is even steeper than I imagined. I'm off to read some tutorials, "I might be gone some time"
I'm not sure of the interface for DSPs to use UI Elements is public.
Although, the EQ uses such a method apparently....O.o
What annoyed me about wcs13 is that at the end of the day, the developer considers the idea, its their option to work out how to best implement said functionality. Developers here ain't drafted into coding for people for free. Unless there is some payment, then realistically, there is nothing wrong with mandating exact specs. But demanding the world for free? People need to be realistic.
No one here asked you to do anything forcibly unless you find proposed idea inspiring then code, without grand imaginations, for whatever noble reason then payment. Poster was offended by your writings and stopped talking to you which your cat persona should know better
If you expect payments, then ask your boss or find yourself a job
I've just this week found foobar2000 as I have a requirement for an audio player with which I can adjust the tempo of ballroom dance music for practice purposes and FooBar, with the Effects DSP (thank you Mudlord), provides what I need. However, for me, it would be easier to use if the Tempo Shift control were on the user interface (like the volume control) and not buried in the Preferences (better still if it could be automated as WCS13 suggests). So while investigating if this was possible I chanced upon this thread.
Okay, I was utterly wrong. The FB2K developer pointed me towards the
dsp_manager class, plus several other SDK methods. Which indeed allows for control of DSPs outside of normal configuration scenarios.
In that case, tempo/pitch shifting via a UI element is planned as another feature. The automation by tags though, won't be. I personally just don't see the point, but I do indeed see the use in controlling DSPs via UI elements.
Poster was offended by your writings and stopped talking to you biggrin.gif which your cat persona should know better
Don't worry, the kitty is now being nicer in future. The kitty would also apologise to OP.
In that case, tempo/pitch shifting via a UI element is planned as another feature. The automation by tags though, won't be. I personally just don't see the point, but I do indeed see the use in controlling DSPs via UI elements.
sorry, about "automation by tags", I don't understand if this functionality will exist or if Foobar don't permit it
I expect that for a long time to adjust pitch
many thanks again for all developers
In that case, tempo/pitch shifting via a UI element is planned as another feature. The automation by tags though, won't be. I personally just don't see the point, but I do indeed see the use in controlling DSPs via UI elements.
Thanks Mudlord - looking forward to it, it will be very useful.
The reason for automating is to help with dancing, especially at dancing lessons and practice where there is a requirement for the music to be within a tempo range. Having to adjust it each time, every time, is an inconvenience it would be nice to be without.
sorry, about "automation by tags", I don't understand if this functionality will exist or if Foobar don't permit it
Said functionality can exist. DSPs can read tags in currently played files if said functionality is implemented.