Why VST??

[CrocoDuck]

Just two more comments, then I think I will have said all I have to say on this.

First, having MOAR speed doesn't equal to better audio performance (it might help, but if I have IRQ issues it doesn't, for example). KolibriOS is much faster than any Linux out of there, but I am afraid you will never do much music on it (not great audio hardware support and pool of software). Speed =/= audio performance.

Recording electrical guitar and the software Guitarix are good examples.
If you talk with a win man about Guitarix, all say without any doubt "that ain't possible!! Tried that many times. Recording distorted guitar is almost impossible without expensive gear".
Why is it that that thought is so common within win recorders? Where we with linux do it without problems.
Then linux DOES handle sound easier and better? Doesn't it?

I am not sure I understand this point. There is plenty of good amp/effect modelling software for all platforms. Guitarix is my favourite, but it is not that AmpliTube sucks. It is expensive sure, but there are many little free jems in the Win world too. I am not sure why the fact we have a good Open Source amp/effects simulator makes the OS handling audio better? The way the OS handles audio... is related to the OS itself, not Guitarix... Maybe you are thinking about low latency that allows you to play realtime? By the way, what's the problem with people claiming that? There is plenty of people the use Guitar Rig in the same fashion of Guitarix on Win... Why the fact that people on Windows don't have good Open Source software (supposing that's true) makes Windows internally handling audio in a worse way? I don't think I get this, sorry.

Does win have no problems at all with hardware and drivers? Does that alway's work well?
When you want win to record you don't have to watch the specs and capacities, and it alway's immidiatly does what you want?
...

Yes, I always struggled with Win. So? You could repeat all those statements with Linux or Mac instead of Windows and they would hold true in many cases. I never had a computer I did not need to deeply tune to be able to make music. Not even when it was an OpenBox system. In fact, for similar reasons you listed there, I moved from Ubuntu to Arch. I found Ubuntu to be too bloated and unstable for audio (I needed to reinstall it from scratch every year, just like XP). I decided to live on a OS that makes somewhat easier to tune deeply the system, so I can squeeze the performance I need. Does it make Arch better? Nope. I just think Arch is good for me and my computers and I will never think it is superior to another distro. There isn't a superior distro.

I always had to struggle a bit to get good audio performance out of Linux. Still, I don't think that other OSes are superior. For one, I always had to struggle with Win and Mac too (good luck uh?). Second, when I get the audio performance I want I think they are perfect. Third, I still enjoy more doing this tuning on Linux as it is the OS I like and makes me much more able and free to experiment. Plus, it runs my favourite software (audio and not). And I like FLOSS.

I am not claiming that Win or Mac are better or easier. They are not. Nor is Linux. Or BSD, or openindiana... Maybe BeOS was it... now it's old. Let's keep an eye on Haiku who knows... But I am not claiming whatsoever that there is a better audio OS or distro, for the matter, and I tried to supply some reason for it.

I once told a friend of mine, that does music on Mac, that I use Linux. He said "Oh cool! If it works for you, more power to you!". A cool guy that doesn't need to convince the world he has the finest and greatest...

Anyway, from me on this subtopic EOF.

[sysrqer]

What i mean. Almost all win users complain that real time recording a 'amp distorted guitar' is hard to record nicely.

This is not true. As has already been mentioned, many windows users record guitar with realtime monitoring using Amplitube or Guitar Rig. I've done it myself.

Like i said: many (all?) win users say that the way i record ain't possible and never ever can give good sound. On new computers.

I think the reality is that very, very few Windows users say this. The very fact that Guitar Rig has done so well and is so popular is proof that this claim is false.

So is it that wrong to say that if i can do easily what others with win can get done very difficult, that linux is easier?

Yes, because you're basing your facts on a limited personal experience versus a falsified and projected opinion of all Windows users. Said opinion is plainly false and has next to no basis of objective truth. So yes, it is very wrong indeed.

And were it's about Guitarix. All guitarix users state it works great with very good sound, where almost each win user say's that way of using/recording is impossible!
???

Both of these statements are false. I have heard quite a few people say they are not happy with guitarix's sound. I've never in my life heard anyone say that this way of recording is impossible on any OS, because it's not impossible and people do it all the time.

96khz on 24bits. Most win don't reach that quality. The all say their system then crashes.

Please stop this, it's just silly. Plenty of people record in 96Khz/24 bit, and sometimes higher, on windows.

I did try it and it worked. Again, on a pentium 4. Ok, not all that smooth, but the system could handle it.
Yet again i'm comparing an old pentium 4 with recent pc's. NOT comparing A with B. Where my pentium 4 wins. Again.
And if it is fast on a p4, it is even faster on a recent pc.

I don't know what kind of stuff you do with music but mixing a song on a core2duo quickly became painful in ardour on my last machine. Crappy old hardware is crappy old hardware. I certainly felt my old machine getting slower and slower as the years passed running linux, the same way you described Windows. I think that is a general trend for software regardless of OS, it tends to get heavier and need more power/ram.

[sysrqer]

And you talk about guitar rig. That's not what i mean.
I talk about recording amp distortion right into DAW.

So you're saying that it is impossible to record an audio signal in windows basically?
Whether you're talking about line in or microphone, both are most definitely possible in windows.

[sysrqer]

So you're saying that it is impossible to record an audio signal in windows basically?

At first, NOT audio, but by amp distorted guitar(s).

And i just explained.
It's not what I say!
It's what i read and hear all the time while MANY OTHERS (far more than one. MANY) say that repeatingly. On several forums and even in my own studio.
I'm just constating that.

Come on man. Please stop discussing about things i didn't even said.

Spreading misinformation isn't helping anyone.

[sysrqer]

You've been online sysrqer.
No answer on my question??

Stalking me now?
You are spreading misinformation. What you have claimed about both Windows and all of it's users is plainly false.

[glowrak guy]

If you repeat the ramblings of 'MANY OTHERS', who have failed to configure audio,
and assert it's credibility, while rejecting common knowledge,
then it's spreading disinformation. Those who have success,
and recognize the successes around them,
are far better sources of accurate information.

Much can be done on a P4, it was 'state of the art' at one time,
and the user-craftiness which make it useful over the years,
hasn't just evaporated. Great music can emerge from a P4.
That doesn't minimize anything else.
Cheers

[glowrak guy]

Ignore list is were you're on now.
Good luck.

You reject the common knowledge that a world of successful audio production exists,
without linux...

"I read it all the time. Hear it all the time. From home recorders mostly that is.
Don't know what they then do wrong, but they themselves say they have recent computers."

"I just conclude on what i read and hear all the time.
If they lie, i lie because of them."

You need to use better forums.

And please don't resort to petty 'ignore-list' technology! This is a forum for linux musicians
to assist linux musians. Disagreement can be the breeding ground of revelations, innovations
and solutions!
This is not facetweet or twitterbook
Cheers

[glowrak guy]

Every day starts out happy and new, even if my back hurts!
Cheers

[ubuntuuser]

I don't understand what's funny here?

That LOL is sarcastic. You don't know the history of my fight for an external UI extension for VST.

The simple idea (also used by Linuxsampler) is to completely separate the GUI code into its own application. Therefor once and for all solving the problem of different GUI toolkits not working together well when used inside the same host.

Unfortuantely host developers refuse to implement it with even the most ridiculous excuses for not doing so. (not scalable, too complicated for plugin developers, "i want my host have control over the window", "i want my host to embedded the your plugin window", you name the bullshit).

So whenever i see some plugin developer again complaining about the toolkit problems and start to code his own i only have a sarcastic LOL.

My own plugins use the external UI extension (even though it is not supported by any host but my own proof of concept host) and have a (simple, but not so nice) fallback so they can be used in any linux VST host ever written, from the very first energyXT from 2006 to the lastest ardour/reaper/bitwig ...

As for the reaper hint: While reaper never calls a plugins "effEditOpen"/"effEditClose" it does call "effEditGetRect" every second time the GUI button is pressed. So a wrapper plugin can use this as the trigger to create a new window and supply it to the "effEditOpen" of the hosted plugin.
Such a wrapper could host LV2 plugins as well of course.

I tried your idea with Linux Native Reaper and a vst wrapper.

I hooked effEditGetRect and put up a X11 window and it works but there is limited control over the vst window closing and reopening because Reaper Linux seems to call effEditGetRect multiple times and when a vst window is closed it then starts up again.

When the vst window is initially opened I just open it from one effEditGetRect call and ignore the others, so it works but the window can't easily be closed and reopened again so far due to the multiple effEditGetRect calls.

It would be great if effEditOpen was called and then it would be pretty easy coordinating the window opening and closing but it isn't and funnily enough effEditClose is called sometimes when the Reaper basic plugin display UI button is hit.

At the moment it's working ok if the window is opened and kept hanging around (and not closed and reopened), until the plugin is removed from Reapers plugin list or until Reaper is quit.

The Carla Patchbay vst works as well.

Here is the vst wrapper hooking one effEditGetRect call and opening a X11 window with u-he's Podolski and everything works with Podolski, the preset loading and the UI controls and the audio etc.

[skei]

Reaper Linux seems to call effEditGetRect multiple times

the windows version of reaper calls effeditgetrect around 5 times per second, by design.. and if the size is different than the already opened editor, reaper will automatically resize the plugin (parent) window..

[ubuntuuser]

Reaper Linux seems to call effEditGetRect multiple times

the windows version of reaper calls effeditgetrect around 5 times per second, by design.. and if the size is different than the already opened editor, reaper will automatically resize the plugin (parent) window..

Thanks, that explains what's happening.

[Drumfix]

If it does so then thats a bummer.
You could ask Justin to stop the periodic calls for the Linux version.

The other thing you could do is to use the workaround i use for the external UI extension:

Tell the host that your plugin does not have an editor, using the vstflags.
Add one extra parameter to the parameter list as the GUI ON trigger switch.
Then whenever the user moves the Gui Trigger, open the plugin window.

What i'd prefer for the host to do, because its the way my external UI extension is supposed to work, is:
- whenever the user presses the GUI button, call effEditOpen with ptr = pointer to UTF-8 string containing the text to be used as the title of the window.
- Never call effEditClose and make no assumption of whether the GUI is open or not.

BTW, great you took the challenge

PS: Just checked back
I was using reaper v5.20r3/64. This is were the effGetRect trick was working.
On the current reaper v5.29/64 the handling of plugin windows seems to have changed considerably.

The workaround with the extra parameter is certainly working in both version though.

[ubuntuuser]

If it does so then thats a bummer.
You could ask Justin to stop the periodic calls for the Linux version.

The other thing you could do is to use the workaround i use for the external UI extension:

Tell the host that your plugin does not have an editor, using the vstflags.
Add one extra parameter to the parameter list as the GUI ON trigger switch.
Then whenever the user moves the Gui Trigger, open the plugin window.

What i'd prefer for the host to do, because its the way my external UI extension is supposed to work, is:
- whenever the user presses the GUI button, call effEditOpen with ptr = pointer to UTF-8 string containing the text to be used as the title of the window.
- Never call effEditClose and make no assumption of whether the GUI is open or not.

BTW, great you took the challenge

PS: Just checked back
I was using reaper v5.20r3/64. This is were the effGetRect trick was working.
On the current reaper v5.29/64 the handling of plugin windows seems to have changed considerably.

The workaround with the extra parameter is certainly working in both version though.

The X11 window version had thread troubles with Reaper and some plugin UI loading.

It kept throwing xcb thread errors in gdb.

I switched to a xcb window and it seems to be ok .

I'n not quite sure of the details of your UI suggestion, if you could fill in more detail that would be great.

At the moment the vst wrapper seems to be pretty functional in Reaper but the window can only be minimized or closed when the plugin is unloaded from Reapers active plugin list.

When the basic Reaper plugin window is closed, then the vst wrapper UI loses the UI because Reaper does something.

It makes me wonder why in the Reaper Linux version they didn't just throw up a xcb window or whatever and do what I'm doing instead of having no vst UI at all, because it's not hard at all and they obviously have effEditOpen and effEditClose coordination etc available, maybe there would be some issues with the vst UI window and WDL or whatever they use, but I've got quite a few vst UI's to load using a basic xcb window and a transparent vst wrapper and they obviously wouldn't need the vst wrapper.

But, I'm not an expert on Linux programming and toolkits or vst's, so maybe they had their reasons for not including a basic vst UI window.

[Drumfix]

An advice for the Window open/close problem:

In reapers VST preferences select the option "Default VST to generic UI"

In your code define a variable

bool ignoreEffEditGetRect = false;

then:

if (reaper calls effEditGetRect ) { // this is done when the gui button is pressed first time

if (!ignoreEffEditGetRect) {
createYourWindow() and call plugin's effEditOpen;
ignoreEffEditGetRect = true;
}
return <your ERECT dummy>
}

if (reaper calls effEditClose) { // this is done when the gui button is pressed second time

if (your window is still open) {
closeYourWindow() and call plugin's effEditClose;
}
ignoreEffEditGetRect = false;
}

This way you control over opening/closing of your window.

As for the X11/xcb problems: Welcome to the world of plugins that are not using the external ui extension.

You will have to implement (=copy from carla or ardour) their GUI code to support all the ways plugin vendors have invented to control their Gui.

[ubuntuuser]

An advice for the Window open/close problem:

In reapers VST preferences select the option "Default VST to generic UI"

In your code define a variable

bool ignoreEffEditGetRect = false;

then:

if (reaper calls effEditGetRect ) { // this is done when the gui button is pressed first time

if (!ignoreEffEditGetRect) {
createYourWindow() and call plugin's effEditOpen;
ignoreEffEditGetRect = true;
}
return <your ERECT dummy>
}

if (reaper calls effEditClose) { // this is done when the gui button is pressed second time

if (your window is still open) {
closeYourWindow() and call plugin's effEditClose;
}
ignoreEffEditGetRect = false;
}

This way you control over opening/closing of your window.

As for the X11/xcb problems: Welcome to the world of plugins that are not using the external ui extension.

You will have to implement (=copy from carla or ardour) their GUI code to support all the ways plugin vendors have invented to control their Gui.

I seem to have got it all coordinated with Reaper's UI button in "Default VST to generic UI" mode.

Thanks for the tips.

If it passes further testing, I might put up 10 vst wrappers (each with different vst names) that load different vst libraries that have been copied to 1.so, 2.so, 3.so etc, if anyone is interested.

That way, 10 different vst's can be used with UI's in Reaper Linux and all the user needs to do is just copy their 10 preferred vst's to 1.so, 2.so, 3.so etc and they can use 10 vst's with UI's in Reaper Linux.

The vst wrapper has no real overhead, so everything is straight through except the UI hook, so the vst plugin within the vst wrapper should just perform like the normal vst plugin.

I've tested u-he Podolski, u-he TripleCheese, drumsynth, 3bandEQ, Obxd, Dexed, Carla-Patchbay16, Drumgizmo and some other vst's so far and all are ok.

I tested Podolski loaded within Carla-Patchbay16 as well.

lsp vst plugins generate a gtk error at the moment, like when the theme can't be found or whatever.