[Request] Enhanced tempo-change component, Dev comments welcome Options

[wcs13]

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 :

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

Mode 4 : BETWEEN MIN BPM AND MAX BPM :

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

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.

[wcs13]

A small correction, sorry :

Mode 3 : TARGET BPM :

4. IF %bpm% > %target bpm%, THEN set TEMPO ALTERATION to 1 - (%bpm% / %target bpm%) (reduce tempo to %target bpm%)

Mode 4 : BETWEEN MIN BPM AND MAX BPM :

5. IF %bpm% > MAX BPM, THEN set TEMPO ALTERATION to 1 - (%bpm% / MAX BPM) (reduce tempo to MAX BPM)

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.

[odyssey]

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...

[wcs13]

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

I hope it helps.

[Canar]

GPLed code cannot be legally used in foobar2000 components. Audacity is GPL.

[kode54]

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.

[mudlord]

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.

This post has been edited by mudlord: Apr 18 2011, 04:59

[wcs13]

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 ). Here's some info about the WSOLA algorithm :

• Wiki : http://en.wikipedia.org/wiki/Audio_timesca...ion#Time_domain
• A Sourceproject page for a WSOLA algorithm : http://sourceforge.net/projects/mffmtimescale/
• The algorithm developer (flatmax) : http://sourceforge.net/users/flatmax
• His web site : http://flatmax.users.sourceforge.net/
• Another WSOLA implementation by flatmax : http://sourceforge.net/projects/mffmvectorwsola/

This post has been edited by wcs13: Apr 18 2011, 12:20

[--pv--]

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.

[mudlord]

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?!

[wcs13]

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.

This post has been edited by wcs13: Apr 18 2011, 17:10

[mudlord]

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.

[q-stankovic]

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)

[wcs13]

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.



This post has been edited by wcs13: Apr 19 2011, 13:37

[Sandrine]

@wcs13
That looks interesting. Awaiting the first release of your component!

[wcs13]

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.

[wcs13]

Some more links for future reference :

• SoundTouch library : http://www.surina.net/soundtouch/
• PaceMaker plugin for WinAmp (similar to foo_dsp_soundtouch but actively developed apparently) : 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.

[Sandrine]

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.

[mudlord]

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........

This post has been edited by mudlord: Apr 21 2011, 01:30

[wcs13]

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). 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 ?

[mudlord]

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.

[mudlord]

CODE

#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.

[wcs13]

[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.

[j_b]

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.

[wcs13]

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 ?

This post has been edited by wcs13: Apr 27 2011, 04:38