SonicBirth v2 alpha

Official support for: sonicbirth.sourceforge.net
Post Reply New Topic
RELATED
PRODUCTS

Post

Kewl wrote: In fact, if the few next alphas could include some of my needed features, I could release some plug-ins in the wild and monitor the response.

What I need: boolean argument, indexed argument, XY pad argument, sample delay with property length in samples and the piecewise circuit.

Thanks!
As well as latency reporting and IDs..!!

Post

makira wrote:Anyone tested the Windows VST export feature ?
I have tested a few simple ones, and it is amazing how straightforward it is !

The open and work without any problem in Reaper, Audiomulch and Bidule but
EnergyXT says that they are not VST plugins.

In Reaper and Bidule they have not their name but instead only "Audiounit", which makes difficult to identify them ;-)
In Bidule, only one is loaded, I suppose because they all have the same name for him.
In Audiomulch they have the good names.

Sometimes they stop working after being unactivated.

Post

Kewl wrote:
makira wrote:Anyone tested the Windows VST export feature ?
Not yet... Not one Windows user at my workplace (but over 100 various Mac models...).
Oh, what a pity :hihi:
Not even a little Bootcamp one ?
In fact, if the few next alphas could include some of my needed features, I could release some plug-ins in the wild and monitor the response.
I am waiting for testing them !

Post

makira wrote:Anyone tested the Windows VST export feature ?
I tested 2 of my plugins on win and they worked fine. In reaper the plugin name was audiounit, in ableton it was the original name.

however in one of my plugins i mad a "random" circuit to add some random into my sound and it wouldn't export to win vst, but was working fine on mac vst and au.
here is the circuit - https://dl.dropbox.com/s/1in6dxyfffhan3 ... .sb2c?dl=1


*Is there any chance we will see soon some gui features so we can get our cool plugins useful? As a user, using the software gui is just not doing it. I know some would say the sound is what important and it's true, but when you record music you also record feelings and vibes witch you don't quit get when using just some grey faders :hihi:

Post

Kewl wrote:In fact, if the few next alphas could include some of my needed features, I could release some plug-ins in the wild and monitor the response.

What I need: boolean argument, indexed argument, XY pad argument, sample delay with property length in samples and the piecewise circuit.

Thanks!
zmix wrote:As well as latency reporting and IDs..!!
leannagia wrote:*Is there any chance we will see soon some gui features so we can get our cool plugins useful? As a user, using the software gui is just not doing it. I know some would say the sound is what important and it's true, but when you record music you also record feelings and vibes witch you don't quit get when using just some grey faders :hihi:
This is a very early alpha, and is only meant for testing. Exported plugins are still not behaving perfectly. The core can still be crashed, etc.

At this stage, it is not reliable, and exported plugins are not meant for distribution (which will stop working anyway after the expiration date). It should not be used in a production environment. I understand the eagerness to use it more, but I recommend patience! :)

Custom guis will be one of the last thing to be added. Perhaps at the end of 2013.

Boolean/indexed parameters can be expected within weeks, latency too. XY pad parameter makes no sense without a custom gui (just use 2 normal parameter and name them x/y ?).

I'm not sure what's the usage case for a delay with the buffer size in samples. A 1000 samples delay will give vastly different results depending on the sample rate.

Currently, the roadmap is roughly this:
  • - Stabilize the core (feedback)
    - Add missing core modules
    - Add missing parameters types
    - Add misc. stuff for plugins
    - Add presets
    - Stabilize exported plugins
    - Add midi support (will take a lot of time)
    - Once everything is working perfectly, add custom gui
Bear in mind the roadmap is likely to change.

The main reason I'm releasing these alphas so early is to catch bugs as soon as possible for the current feature-set that is implemented.

Post

makira wrote:I'm not sure what's the usage case for a delay with the buffer size in samples. A 1000 samples delay will give vastly different results depending on the sample rate.
At least one: time alignment between microphones in a stereo or multi-channel recording.

In MS recording, time alignment of a few samples can have quite noticeable effects. See the last section of this page: http://www.radio.uqam.ca/ambisonic/native_b.html

Post

makira wrote: I'm not sure what's the usage case for a delay with the buffer size in samples. A 1000 samples delay will give vastly different results depending on the sample rate.
Is latency not reported in samples? I set up all of my delay circuits by multiplying the sample rate times 0.001 in order to give a simple delay parameter in milliseconds, perhaps a reverse calculation will be required if the reported latency is required to be in ms.

Post

The delay element has its buffer lenght in seconds. Its delay input is in samples.

Kewl, for your usage case, something like a 0.1 seconds is probably enough to cover all cases (0.1 seconds corresponds to about 30 meters considering the speed of sound). Whatever you had in mind for the buffer max length at a given samplerate, convert it into seconds.

Now for the actual delay used, wheter you present samples or milleseconds or seconds (or even meters!) to the user is up to you. Just convert whatever you present to samples for the delay element input.

As for the reported latency of the whole plugin, like in v1, it will be milliseconds + samples.

Post

makira wrote:Kewl, for your usage case, something like a 0.1 seconds is probably enough to cover all cases (0.1 seconds corresponds to about 30 meters considering the speed of sound). Whatever you had in mind for the buffer max length at a given samplerate, convert it into seconds.

Now for the actual delay used, wheter you present samples or milleseconds or seconds (or even meters!) to the user is up to you. Just convert whatever you present to samples for the delay element input.
Antoine, in a MS setup the correction needed can be as little as three or four samples.
The delay element: its property length is in seconds, but the dl input is in samples.
The problem here with the conversion from "whatever to samples" is that it varies with the sample rate. To have access to the sample resolution, I must divide a unit by 44100 at 44.1 kHz, but I must divide it by 192000 at 192 kHz. How can the plug-in keep track of that? Is that the use of the "Global samplerate" element?

Post

Or I just don't understand how the delay element works now...

Post

makira wrote: Now for the actual delay used, wheter you present samples or milleseconds or seconds (or even meters!) to the user is up to you. Just convert whatever you present to samples for the delay element input.

As for the reported latency of the whole plugin, like in v1, it will be milliseconds + samples.
The point of my internal conversion is to make the delay time independent of the sample rate. I'm wondering if the same calculation can be used to make the latency compensation independent of the sample rate, also?

Post

Kewl wrote:How can the plug-in keep track of that? Is that the use of the "Global samplerate" element?
If you want to present samples to the user, just create a parameter samples with min 0 max 100 and plug that directly in the delay element.

If you want to present milliseconds, yes, you can simply use milliseconds * samplerate / 1000 to get samples. Presenting milliseconds doesn't mean you lose single-sample precision. The numbers are different but the precision is the same.

The 'Globals samplerate' element is indeed the current sample rate the audio unit is running at.

As for the buffer length property, if you use 0.1 seconds, the max buffer length will be 4410 samples at 44.1 khz and 9600 samples at 96 khz, both of which will be more than enough for your usage case. Yes, if you intend on never using more than 1000 samples, a bit of memory will be wasted, but so little it is negligible. If that's really a bother, I guess I could add support for specifying the max buffer length in samples.
Last edited by makira on Thu Dec 13, 2012 7:17 pm, edited 5 times in total.

Post

zmix wrote:I'm wondering if the same calculation can be used to make the latency compensation independent of the sample rate, also?
Yes, that was implicit by being able to specify it in milliseconds + samples, exactly like v1 does. Before reporting the value to the host, the milliseconds part is properly converted to samples depending on the current sample rate, as in v1.

Post

makira wrote:the buffer length property
Ha! Now I think I get it. What you initially called the "length property" is a buffer. So, then, it's value can't be 0, right?

I set the buffer to the max length that I need and then I control the delay with the dl input, from 0 to the max length set in the property, right?

Post

Kewl wrote:Ha! Now I think I get it. What you initially called the "length property" is a buffer. So, then, it's value can't be 0, right?

I set the buffer to the max length that I need and then I control the delay with the dl input, from 0 to the max length set in the property, right?
Yes. The only catch is that the length property is currently in seconds, while the input port of the element is in samples. I'll add a way to specify the length property in samples, so everyone's happy.

I should really start a manual...

Post Reply

Return to “SonicBirth”