Signalizer: Sidechaining update! Open-source & free audio visualization plugin (v. 0.4.3)

VST, AU, AAX, CLAP, etc. Plugin Virtual Effects Discussion
Post Reply New Topic
RELATED
PRODUCTS

Post

Valid points made, old friend...
brok landers wrote:- the grid color is coupled with the color of the readout peak window. but i would like to set up the grid rather not so bright, however - the readout should be bright and clearly readable. could you maybe decouple these 2, so that one can set these up independantly?
I'd love to see this as well. Maybe even with actual color picker and like 20 colors to chose from rather than a knob to select.

brok landers wrote:- with such a vast amount of set up options it would be nice to have a nice, indepth but not only technical manual. i'm 25 years in the profesional studio business, yet on a lot of parameters i don't have a clue what they are good for, nor do i know what they do... :)
Yes - definitely a manual please. I'm in the same boat as Brok and metering tools are kind of my pet peeve.

brok landers wrote:- could you maybe implement a metering window, that can be displayed next to the analyser? right now i have to use another plugin for that, which prevents me from being able to use the analyser in fullscreen mode. i use a third monitor exclusively for measurement tasks, so that would be wholeheartedly welcome...
Sandbox mode was answered to one of my last posts as "possibility" in a future update (after all other kinks are ironed out). Various types of signal strength meters as well (that cold be a sooner possibility).

I see where you aim at. Though maybe for the time being, Vengeance Scope (free in the Computer Music magazine "suite") or DMG Audio's Dualism might be the better solution for you
[ Mix Challenge ] | [ Studio Page / Twitter ] | [ KVRmarks (see: metering tools) ]

Post

I join the manual chant. Especially a human understandable explanation of the different algorythms and their practical impact would be oh so good. I have a vague idea about the operation modes but a real world application difference in simple terms would be <3 to get the most of it.
aka rktic. demoscener, sound designer, ux-dude, human synthesizer—not necessarily in that order.

Post

Compyfox wrote:Maybe I should jump to Mail reports or something? The posts are staring to get a little bit confusing.
I think we can just manage, I would prefer to keep discussions in public if possible. Regarding the tabs, so to clarify the issue: If you want to open the view-specific settings, you have to select the view and then click the cogwheels to the left? If that's the case, how would you open the global settings then?
Not talking white or pink noise, but DIRAC. Actually tested "Rectangular", no change really. Test signal is also (strangely) at -52dBFS on the analytic view
..
I'm using Spectrum view, and the Update speed. There is no frame rate setting to edit here.
..
I think you should take a look at Christian Budde's VST Plugin Analyzer, "Frequency Analysis", Domain: Phase.
Okay, I get what you're after: It's called a bode plot. For technical reasons, this is not possible since Signalizer is not in any way synchronized to the plugin's impulse output (I can display phase results, but it would vary randomly each frame lead to a fog of noise...). The VST Plugin Analyser can do this because it hosts other plugins in a controlled environment, I do not. However, this problem will be solved once (or if) I add scripting support to the views.
Actually, I found out that the "grid" has been colored "black", so the colors reset on project/host reload. So if you select Line Graph from the Dropdown, it's "Nautical" due to the missing (black/transparent) grid.
Yes, the difference between 'analytical' and 'nautical' is just colours - predominantly, that the grid is being rendered in invisible colours.
Wait, "your" company is Lightbridge, or it is the company name of the tool you used to program Signalizer?
I'm confused.
'Lightbridge' is the company name, only because you have to have something to display through the vst/au specs. Signalizer is coded natively.
Peak Decay and RMS as "auto gain" are taking things too far.
The set of features you're looking at is (beyond some stuff added in .2.7) is solely what I want/find important for my needs.

Regarding the black text on background; I'm on it.
Mayae wrote:But does that mean no changes persist through project openings/closings? Like, if you set some knob to some value, and save the project, the knob will be reset upon loading of the same project again?
The change "persists", but only half of the settings seem to be forwarded.
Also, it really depends on the host. Like I earlier wrote - WL8 behaves different than WL9, which also behaves different to Cubase.
This sounds extremely buggy/wrong. Have you have any prior experiences like this? I think the only think that can help me investigate this is for you program an arbitrary preset in Signalizer and save it through the global menu. Now save this in a project. Recall the project, and save the preset again. Send the two different files to me.
Taking note of the recent posts prior to me, I'm not hte only one reporting slowdowns or even no GUI's at all.
GUI missing or lagging is vastly different to FPS slowdowns (it's two different graphic subsets entirely, the menus and GUI are programmed in software whereas the graphic views are rendered in OpenGL).
Speaking of "no GUI"... I found out that in Wavelab, the first time you open the Spectrum View, the signal shown on the graph is super low, even if the input is at -10dB RMS... This could be a potential bug.
In the spectrum?
I think this is why you used OpenGL, to have a unified source for rendering on all engines. Still... I'd say that OpenGL 2 should remain absolute minimum for all rigs, and you should try to optimize the code as good as you can.
This is of course something I want to do, but it takes time - time away from features and bugfixes.
This is why I mentioned 3 sizes in 16:9 and a custom panel for those that want "custom sizes" (manual resizing to given numeric values). Something that Kontakt (at least up until Kontakt 4) does not offer. If you then save your settings globally, it should be recalled like you set it up.

There... one global settings, only needed to be setup once.
So the global settings will be the choice of window sizes?

Post

brok landers wrote:hi mayae,

first off a very big thank you for this marvellous plugin, i absolutely love it. i'm doing a lot of mixing and mastering as well as sounddesign as my main job, and this plugin is by far the best analyser i had my hands on. and that for free (!!). so again, thank you for that.
Why, thanks a lot for the kind words and I'm happy it's usable.
- the slope value (high frequency vs. low frequency) is not stored in the presets.
Right, noted.
- even with a short audiofile there are spikes, meaning when i play f.e. a kick in cycle, the individual frequencies have different amplitudes every time. sometimes the click (2-5khz) of the kick has say-30db, next time it has -20db, even if nothing in the signal obviously changes.
- in low frequencies (f.e. a kick), initially theres a build up, meaning the kick has to run 3 or 4 times trough the analyser to be correctly displayed.
This is expected behaviour. When you run a signal through a window, peaks of the audio gets randomly placed inside the window depending on the overlap used. To get actual verifyable numbers, the program would have to run the analysis for each sample. Otherwise, just use a rectangular window and select a buffer size large enough to ensure overlap. When (or if) scripting support gets added, this issue will be addressed as well.
- the grid color is coupled with the color of the readout peak window. but i would like to set up the grid rather not so bright, however - the readout should be bright and clearly readable. could you maybe decouple these 2, so that one can set these up independantly?
This makes sense, noted.
- could you maybe implement a metering window, that can be displayed next to the analyser? right now i have to use another plugin for that, which prevents me from being able to use the analyser in fullscreen mode. i use a third monitor exclusively for measurement tasks, so that would be wholeheartedly welcome...
As noted above, this would require the sandboxing feature, which is still in some unknown point in the future.
Compyfox wrote:I'd love to see this as well. Maybe even with actual color picker and like 20 colors to chose from rather than a knob to select.
You have discovered the fully accurate HSV and RGB colour picker, right?
- with such a vast amount of set up options it would be nice to have a nice, indepth but not only technical manual. i'm 25 years in the profesional studio business, yet on a lot of parameters i don't have a clue what they are good for, nor do i know what they do... :)
Ronny Pries wrote:I join the manual chant. Especially a human understandable explanation of the different algorythms and their practical impact would be oh so good. I have a vague idea about the operation modes but a real world application difference in simple terms would be <3 to get the most of it.
Compyfox wrote:Yes - definitely a manual please. I'm in the same boat as Brok and metering tools are kind of my pet peeve.
A manual is definitely required (there's also a lot of undocumented behaviour), and I wouldn't mind writing one, but again - time.

Also sorry for being late to answer, I've caught another flu so that will delay stuff some more.

Post

Okay, frustration due to the quote pyramid sets in... it's so much simpler via mail.

Mayae wrote:Regarding the tabs, so to clarify the issue: If you want to open the view-specific settings, you have to select the view and then click the cogwheels to the left? If that's the case, how would you open the global settings then?
This is fairly simple to understand. But I was mentioning that sometimes the rotating arrow doesn't work. Maybe make that area to click on a bit bigger and/or design it a bit different.


Mayae wrote:Okay, I get what you're after: It's called a bode plot. For technical reasons, this is not possible since Signalizer is not in any way synchronized to the plugin's impulse output (I can display phase results, but it would vary randomly each frame lead to a fog of noise...). The VST Plugin Analyser can do this because it hosts other plugins in a controlled environment, I do not. However, this problem will be solved once (or if) I add scripting support to the views.
I assume the whole "view" I'm after is the Bode Plot - for both Frequency "Magnitude" (the plot I linked earlier) and "Phase" as special application (looks like I don't know that many measurement "types" after all). Maybe even to measure out the transfer curve of distortion devices, or compressors (ratio view, etc).

However, if this will be possible with an update/script - I'm game for that feature.



Mayae wrote:Yes, the difference between 'analytical' and 'nautical' is just colours - predominantly, that the grid is being rendered in invisible colours.
The problem is... the grid reverts back to "invisible" if you recall a host project (Cubase), or reload the host (Wavelab). Also... the dropdown menu for the view type is with a transparent/black grid - it's not colored on default.

So the two default views are "Nautical" and "Color Spectrum". The grid only shows up if you change the color or load the "Analytic" preset.


Mayae wrote:You have discovered the fully accurate HSV and RGB colour picker, right?
No - as mentioned before - the lack of a manual turns this whole tool into a guessing game. And I was never big on finding easter eggs in anything software related.


Mayae wrote:
Wait, "your" company is Lightbridge, or it is the company name of the tool you used to program Signalizer?
I'm confused.
'Lightbridge' is the company name, only because you have to have something to display through the vst/au specs. Signalizer is coded natively.
Then add your name as "Company", not the company of the product you "code" your plugin in. It's your project after all, even if it's Open Source.

So the ID's should be:
Company: your name
Plugin name: the name of the plugin

Users that use hosts without a plugin search function will have a hard time finding your tool otherwise.


Mayae wrote:This sounds extremely buggy/wrong. Have you have any prior experiences like this?
With your tool only, no. With beta testings for other companies... plenty.


Mayae wrote:I think the only think that can help me investigate this is for you program an arbitrary preset in Signalizer and save it through the global menu. Now save this in a project. Recall the project, and save the preset again. Send the two different files to me.
This... will take a LOT of time and work to test and is not guaranteed to offer the results you're after I'm afraid. Like I said, each host interprets the VST Plugin Technology differently. Each host also behaves differently on project and/or host reload, what parameters are being recalled. This is where code workarounds start to happen, and is the most frustrating and time consuming thing during beta testing.



Mayae wrote:
Speaking of "no GUI"... I found out that in Wavelab, the first time you open the Spectrum View, the signal shown on the graph is super low, even if the input is at -10dB RMS... This could be a potential bug.
In the spectrum?
Yes, in the Spectrum View.

Once more:
If I load this plugin, not my preset is loaded but the default one. This has the "Nautical view" (transparent grid). And even though the settings are on default and the input signal is at -10dB RMS, the signal peaks are barely there. I have to move around the GUI, or resize it manually, etc... before the frequency spectrum (FFT) is shown correctly.

To me, this is a bug.


Mayae wrote:
I think this is why you used OpenGL, to have a unified source for rendering on all engines. Still... I'd say that OpenGL 2 should remain absolute minimum for all rigs, and you should try to optimize the code as good as you can.
This is of course something I want to do, but it takes time - time away from features and bugfixes.
Then create a DEFAULT preset for your next version, where the AA is set to 2x rather than 16x, and you already added that "flood" fix as well. This should drastically improve things. Maybe even restrict the plugin to 8xAA or even just 4xAA max.


Mayae wrote:
This is why I mentioned 3 sizes in 16:9 and a custom panel for those that want "custom sizes" (manual resizing to given numeric values). Something that Kontakt (at least up until Kontakt 4) does not offer. If you then save your settings globally, it should be recalled like you set it up.

There... one global settings, only needed to be setup once.
So the global settings will be the choice of window sizes?
[/quote]

I think we're stumbling constantly into a language barrier here, and this is starting to frustrate me.

- Create an extra panel in the global settings that takes care of the window size (which can be saved as default preset).
- the sizes should be 960x540, 1280x720, 1920x1080 or a "custom value" (with two manually insertable values)
- either select one of the three or go for the "custom value"
- save to the default preset
- next time the plugin is loaded, it uses that screensize for the GUI INCLUDING the settings tabs.



I think at this point, I'll wait for 0.2.8 before I test any further.

Just one question out of interest:
Which signal strength meters do you plan for a future update?
[ Mix Challenge ] | [ Studio Page / Twitter ] | [ KVRmarks (see: metering tools) ]

Post

Please dont be frustrated, it's the last thing I want my software to do! :) And please understand, I only ask for clarifications in case of ambiguity.
Rest assured I will work on the issues you presented (they've all been noted), and perhaps your experience will be more fruitful once I get around to writing the manual. I'll try to test the hosts. And feel free to e-mail me for any other issues or continued discussion, if need be.
Then add your name as "Company", not the company of the product you "code" your plugin in. It's your project after all, even if it's Open Source.
Lightbridge is my company :)
Like I said, each host interprets the VST Plugin Technology differently. Each host also behaves differently on project and/or host reload, what parameters are being recalled. This is where code workarounds start to happen, and is the most frustrating and time consuming thing during beta testing.
This should not be the case, the spec is a spec for the sole reason that hosts should obey it. Now in this particular case, the plugin doesn't even have exposed parameters (at all) so the host can't even tamper with them. The only case left is binary corruption in the plugin preset storage in the project (which was the reason behind the request).
Which signal strength meters do you plan for a future update?
Nothing planned yet, there have been suggestions and feel free to leave more.

Post

Mayae wrote:Please dont be frustrated, it's the last thing I want my software to do! :) And please understand, I only ask for clarifications in case of ambiguity.
I can understand that...


Mayae wrote:Rest assured I will work on the issues you presented (they've all been noted), and perhaps your experience will be more fruitful once I get around to writing the manual. I'll try to test the hosts. And feel free to e-mail me for any other issues or continued discussion, if need be.
For more detailed reports, I think I'll go this route from now on.


Mayae wrote:
Then add your name as "Company", not the company of the product you "code" your plugin in. It's your project after all, even if it's Open Source.
Lightbridge is my company :)
Oh... did we already mention that a manual would be great?
Also... your page is going by your real name - not your company name. Hence the confusion.


Mayae wrote:This should not be the case, the spec is a spec for the sole reason that hosts should obey it. Now in this particular case, the plugin doesn't even have exposed parameters (at all) so the host can't even tamper with them. The only case left is binary corruption in the plugin preset storage in the project (which was the reason behind the request).
One thing I learned as a beta tester in the last 10-15 years... DO NOT underestimate hosts and their VST interpretation of the SDK. You can stick to the specs as much as you want, it can be by the numbers, yet there can still be something out of your hands (ot the host devs) that doesn't want to add up.

And this is where the frustration kicks in. For users, for host devs, for the tool developer. I've been there - several times.


Mayae wrote:
Which signal strength meters do you plan for a future update?
Nothing planned yet, there have been suggestions and feel free to leave more.
I'll think I'll write you separately on that.
[ Mix Challenge ] | [ Studio Page / Twitter ] | [ KVRmarks (see: metering tools) ]

Post

Mayae wrote:
brok landers wrote:hi mayae,

first off a very big thank you for this marvellous plugin, i absolutely love it. i'm doing a lot of mixing and mastering as well as sounddesign as my main job, and this plugin is by far the best analyser i had my hands on. and that for free (!!). so again, thank you for that.
Why, thanks a lot for the kind words and I'm happy it's usable.
no need to thank me - it is well deserved.

Mayae wrote:
brok landers wrote:- even with a short audiofile there are spikes, meaning when i play f.e. a kick in cycle, the individual frequencies have different amplitudes every time. sometimes the click (2-5khz) of the kick has say-30db, next time it has -20db, even if nothing in the signal obviously changes.
- in low frequencies (f.e. a kick), initially theres a build up, meaning the kick has to run 3 or 4 times trough the analyser to be correctly displayed.
This is expected behaviour. When you run a signal through a window, peaks of the audio gets randomly placed inside the window depending on the overlap used. To get actual verifyable numbers, the program would have to run the analysis for each sample. Otherwise, just use a rectangular window and select a buffer size large enough to ensure overlap. When (or if) scripting support gets added, this issue will be addressed as well.
well - it might be expected from a technical perspective due to the algorithm, but for sure is not expected from the users pov. if i send the exact signal to an analyser, everytime i do so the analyser should show the same pic of course... :)
but i will try to check out the settings you have pointed to - maybe things get better then.
btw - this exactly is why we need a manual... :)

get well soon, and keep posting here, please...
thanks again for the marvellous work!
regards,
brok landers
BIGTONEsounddesign
gear is as good as the innovation behind it-the man

Post

Up, any news ?

Post

Hi brok, sorry I missed your reply.
brok landers wrote:well - it might be expected from a technical perspective due to the algorithm, but for sure is not expected from the users pov. if i send the exact signal to an analyser, everytime i do so the analyser should show the same pic of course... :)
but i will try to check out the settings you have pointed to - maybe things get better then.
btw - this exactly is why we need a manual... :)

get well soon, and keep posting here, please...
thanks again for the marvellous work!
You're welcome, and I managed to survive the flu - once again. Yes, there are multiple 'points' that should probably be elaborated in the manual. :)
lolilol1975 wrote:Up, any news ?
Hi, you can subscribe to the mailing list which will be the preferred medium to push any sort of updates from me:
http://jthorborg.com/mailman/listinfo/s ... orborg.com

Unfortunately, there's yet to happen anything (publically) at least. I've got huge amounts of feedback, features and ideas and I'm trying to wrap my head around design decisions; a lot of these requires some behind-the-scenes work that isn't so sexy feature-wise but in the long run scales a lot better.

Currently, I've implemented some bug-fixes for 2.8 and am developing the basic parameter system that
1. Allows all parameters to be automated from the host
2. Allows Signalizer components to be scripted
3. Allows much easier integration of Signalizer components in other software

But it will take a bit more work. Hopefully I'll have more time in the upcoming month.

Post

Nice, but could we have a simple version with the oscilloscope and the stats first before the complicated automation ?
They are more useful for most people and it seems you have already developed as you showcased the oscilloscope in one of your videos.

Post

lolilol1975 wrote:Nice, but could we have a simple version with the oscilloscope and the stats first before the complicated automation ?
They are more useful for most people and it seems you have already developed as you showcased the oscilloscope in one of your videos.
The oscilloscope you're referring to is just a preset of the vectorscope, which is included in all public versions so far.

I'll develop features as I see fit; as said, I realize some of the work is probably not the sexiest but I'd rather have a solid foundation to build on, than rush stuff into an unmaintainable mess. It's a product that implements and showcases an open-source framework intended for other purposes as well, not a money-making/people-pleasing machine. No offense - at all - just to elaborate on my motivations :)

Post

Just tested this in Live 9 32 bit. Win 7, gtx 970.

Looks really good. I switched through some presets and it's very useful to me.

After a few minutes i switched to the first tab, Vectorscope, and instantly live 9 crashed.

Post

zeep wrote:Just tested this in Live 9 32 bit. Win 7, gtx 970.

Looks really good. I switched through some presets and it's very useful to me.

After a few minutes i switched to the first tab, Vectorscope, and instantly live 9 crashed.
Sorry to hear about this. The program should have generated an exception log ("signalizer exceptions.log") in the folder of the plugin. Can you check if its there - and send it to me?

Post

The signalizer exceptions.log file wasn't there unfortunately. I will try to reproduce the crash.

Post Reply

Return to “Effects”