I'm a dj and would much rather use SS for my MixVibes dj pc program instead of outboard compressor/limiter/expander.
We were just testing this on a few systems earlier today, running Mixvibes DVS, two running RME Firefaces, and one running a Linx. It seemed to work great with 64 sample latency in DVS.
Oh and by the way, you can do the same thing with Winamp and the right input & output plugins... there's tutorials already on this forum that will show you how, use the search function.
Cheers
But how to solve the problem with the delay in ss2?
? Impossible to broadcast with 2seconds delay.
We did lower the latency of TPP a lot, but it doesn't perform well at all with very low latency. We couldn't get it much under 4096 samples for input and for the output, without being unstable, and not under 1024 samples for the ringbuffer after the DSP (i think because of winamp plugins needing minimum of 576 sample buffers unless they buffer right into the output). But either way, you're not going to get that great of latency unless you are using Kernel Streaming, which MMTools (some of the Delphi classes used in TPP) does not support by itself.
To Alessandro:Great tool, I only have a couple suggestions.
The 1st is a big one, that it could be set not to pause the DSP plugins when there is silence or near silence. This causes Oddcast to stop sending data, and it also seems to trigger when there isn't near-silence, but also if there's loud parts next to parts that are like -70db (where near-silence would be like -90db ish) If there's "bouncy" dynamics like that with big dynamic range, then it pauses the DSP chain for split second and it sounds like glitching on the stream cos Oddcast is pausing for a split second. We tried removing the meters and connectors, because of the pausing functions in them, but that didn't remove the problem of the DSP pausing. We also couldn't find any info on the MMDSPPlugin class anywhere, is that your own code? We tried using TMMTrigger, but that didn't get included with the app cos the linker removed it, i'm sure. Anyways, that's the first suggestion, don't ever pause the DSP.
The 2nd suggestion is to use TMMWaveRecorder to save an output wav from AFTER the DSP (obviously). Just save it to the same directory with the date/time stamp as part of the filename should be fine, or to provide a way to name it before it starts saving (TMMWaveSaveDialog) if that's possible. Actually,
ideally it would be awesome to be able to save to mp3 using lame_enc.dll, but that might be a far stretch this early in development. But yeah, saving to mp3 with lame_enc.dll with a few settings in the ini (like what Oddcast uses) using a date/time-stamp as part of the filename would be the bomb.
The 3rd suggestion is to integrate this into your EXE's manifest - if MMTools does indeed require administrator rights under Vista:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity version="1.0.0.0" processorArchitecture="X86" name="nameOfYourApp" type="win32"/>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="requireAdministrator" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
That will cause Vista's UAC to automatically run the program with administrator rights if the current user is an administrator, and if the user is not an administrator it will open a form asking them to enter the credentials of an account that has administrator rights. I had to read through almost 500 page word doc to figure that out.
It's easy once you know though, isn't it?
But yeah, awesome tool. I look forward to whatever updates you might be doing to it.
