Impulse convolver/guitarix

[brummer]

Hi Garry

I did wonder if It was worth handling external apps at all ( jconv included, seeing as the port handling for that works fine as is). With external apps you are gonna have to connect their outputs via qjackctl or patchage whatever anyway. What's your thinking on this? Where do you see the advantage?

It's worth for me, to have a look at the jack audio world outside guitarix, indeed, this feature didn't wone replace qjackctl/patchage, but it gives a overview of the possible connections for guitarix. It's anyway a part of the intercommunication between jack apps.
Ppl coming from the windows or MAC side, may get a impression of what jack can do.

brummer

[thorgal]

hey Garry,

I don't like qjackctl.
EDIT: what I mean is that the app is cool to have, but to use is sometimes a PITA. You would always have to have it on, go back to it to make connections, etc. I find it annoying most of the time. When jackd is running, I want to forget it. That's why I implemented these "smart" jack features in guitarix. Jackd can die, guitarix can disconnect, and you can quickly connect / disconnect its ports to any other client. SO that's the deal, no qjackctl involved, no terminal involved, and (hopefully) graceful behavior when external clients or even jackd itself screw up and comes back to life.

I will see if I can reproduce the issue you mentioned. Is it any linuxdsp client ?

[GarryO]

Thanks for sharing your thoughts, guys. I don't necessarily disagree with you. I was more curious than anything. And I _do_ agree about qjackctl being a PITA.

Being able to access ports like this is really quite a novel feature: the only other app I can think of that has anything similar is Ardour, and that works a treat.

@Thorgal: the problem appears to be common to all linuxdsp plugins : I tried the overdrive, graphic eq, para and shelving eqs, reverb, distortion, sustainer and compressor. They all exhibit the same behaviour: the ports don't go away when you kill the plugin. Restarting guitarix clears them out.

Everything else I tried: jamin, jackrack, lv2rack, fmit, meterbridge, jaaa, japa etc, etc, worked as advertised. Even tapreverbed worked fine ( it crashed guitarix the last and only other time I tried it).

[StudioDave]

Jumping in here for a quick note: I just built SVN rev 354 on my Jaunty system and I am impressed with the new features and the GUI improvements. Haven't tested its sounds yet, Ivy's still sleeping.

Excellent development, my compliments to the crew.

Best,

dp

[thorgal]

Ciao Dave,

Thanks for the praise
We have more to come, we'll let you know! I have something under the sleeve that may appeal to a few users other than myself. Don't know when I am done with it though

oh yeah, I have reworked the level meters and they use much less CPU now. I have (shamelessly) ported the code from ardour (conversion C++ based gtkmm2ext to GTK C style). The look needs a bit more polish but the functionality is already in svn.

[GarryO]

Re svn@358: I'm getting crashes with jconv enabled on startup again.
Its a bit more intermittent than previously: restarting a second time often works ok.

A strange thing happened when I built svn@354: the gui had a rather neat look that I hadn't seen before. Each control had a subtle discrete panel around it. I thought i'd try the other colour schemes and lost it. Couldn't get it back. I tried deleting .guitarix and doing a complete reinstall to no avail.
( I normally do a ./waf uninstall then build a new version with a completely fresh download.)
What do you think happened there? Did I imagine It? Am I missing something?

[thorgal]

Hi Garry,

No you were not dreaming brummer introduced a cairo based skin.
I have updated a few things. I cannot reproduce the jconv thing. Could you update to the latest svn ? I improved on the meter display with a gentle falloff speed.

Let's see if you have a jconv problem again.

svn@360

[GarryO]

Re svn@362 : well whatever the jconv problem was, it's not there now. The only remaining glitch is that if you close guitarix with jconv running, then on restarting the "run jconv" button is lit up as if jconv was enabled although its not.

The new cairo skin is really nice - I guess I need some new specs because there it is plain-as-day in the skins menu. Duh!

@Thorgal: Did you get to the bottom of the linuxdsp thing? I see you didn't get a response on LAD yet. Mind, if linuxdsp open-sourced their stuff it wouldn't be hard to figure out what they were doing wrong.

Another trivial fault: with cairo skin, save as main setting, close guitarix. restart guitarix, cairo skin ok, but skins menu shows black skin enabled.

Looking and sounding good, guys!

[brummer]

The only remaining glitch is that if you close guitarix with jconv running, then on restarting the "run jconv" button is lit up as if jconv was enabled although its not.

Hi Garry
, indeed the button is green when you start guitarix with jconv set to run, there is a timeout from 500ms befor starting jconv in this case, do you mean that, or is jconv didn't start at all ?

@Thorgal: Did you get to the bottom of the linuxdsp thing? I see you didn't get a response on LAD yet. Mind, if linuxdsp open-sourced their stuff it wouldn't be hard to figure out what they were doing wrong.

Yes, we could solve it, we add a exception to the port handler, special for linuxdsp plugs, they have a strange behaviour when they exit from jack, indeed, if they are openSource, we would send a patch to mikel.

Another trivial fault: with cairo skin, save as main setting, close guitarix. restart guitarix, cairo skin ok, but skins menu shows black skin enabled.

Didn't that happen anyway ?

Glad you like the cairo skin,

brummer

[GarryO]

This is what happened: I loaded a _jconv preset_. I closed guitarix with jconv enabled. When I restarted guitarix the jconv button was lit up as if enabled, but the preset was not remembered. So jconv did not do anything because there was no impulse file.
Now once I loaded an impulse file from the _jconv settings dialog_ the file is remembered, so jconv works as expected. No problems after that.

The linuxdsp thing is no big deal. I was only using it for testing. Just curious.

Didn't that happen anyway ?

I don't know. I would expect it to show the actual skin in use, that's all.

[thorgal]

about the skin: the widget is not refreshed, that's why it does not always reflect the current skin.
@brummer: we should probably do something like for the jack latency widget.

[funkmuscle]

jack latency widget... yes, yes!!!
guitarix is looking great guys and I can use it again the way I use to. just run guitarix separately from jconv.
looks and sounds better guys.

[GarryO]

@Thorgal: Again no big deal. To make things clear: I'm just reporting what I find, in the hope that it will be of use or interest to you. If it is, then I will benefit as a user. If it's not, it's not. But don't think I'm nagging you to fix every tiny thing.

[thorgal]

@Garry: no prob, I actually prefer you report all these details. I've been aware of this little thing for as long as I can remember (since I started working on the menus) but never got around to do it (some things are more exciting to implement than others ).

Talking about that, I hope I'll find some time to implement something really cool I'll let you guys wonder what this is about ...

[brummer]

@brummer: we should probably do something like for the jack latency widget.

we have it implemented already, it just didn't work for this case.
Problem is, jconv recive a pid when it try to start, we check the pid, see it is value, and go on.
I have add a check for if jconv is "really" running (the old system call) and now it works.

Hey Garry, many thanks for your reports, be sure, it is highly interested for us, special your clear indication of a properly problem helps a lot to reproduce it and fix it.
We need comments like yours to push guitarix forward.