When attempting to add one of those plugins to a track, typing in the name brings no result. Path to the .vst directory is correct.
Odd behaviour, as i never had the problem before and the plugin loads in previous sessions.
cheers
this from the 'message' window where the plugin is present...
/home/me/Desktop/Protoverb.log
no deskTopFile found
preset=initialize
Trying setUniqueID(1969770582)...
setUniqueID (1969770582)
Saving registration code to /home/me/.u-he/Protoverb/Support/com.u-he.Protoverb.user.txt
failed to open /home/me/.u-he/Protoverb/Support/com.u-he.Protoverb.user.txt to read registration key
HOST 'Qtractor'
API 'VST2'
Starting REVISION 4408
DelayNetWorks random 166.11 after 14277 rounds
Using vector extension SSE3
new instance of AM_PreferencesAudio created for Protoverb # 1
Structure 0 - 5
HW8
Wide
loadPreferences() - Protoverb
void AM_AudioMan::createMidiPrograms()
Preset from 'Protoverb'
Params: press button
AM_DelayNetWorks::setParameterComplex
Structure 0 - 0
HHD
Wide
Seed 0
OMG... need to reseed
DoublettesInRange 0.00
collisionLaw ran 15 tests
No Bridges
stateInfoLevel level back to 0
AM_AudioMan::reset()
getMidiAssignPath(): /support/com.u-he.Protoverb.midiassign.txt
READING midiAssignFile
Odd behaviour, as i never had the problem before and the plugin loads in previous sessions.
you mean that the plugins, inserted on previously existing sessions files, loads fine? but trying to add a new they just doesn't show up on VST plug-in discovery/selection?
if that's so, try first to backup your ~/.u-he directory, where you installed your U-he plug-ins, and start re-installing one by one from scratch on a new and empty ~/.u-he directory; on each install, test whether the VST discovery process is successful, by showing up on listing, one at a time; if none appears still, then it's some other VST plugin, not from u-he, that is crashing the discovery process too early: you'll have to investigate which one is the culprit, by starting over from ~/.vst contents perhaps.
maybe, just a suggestion, you can start by backing up ~/.vst to somewhere else, say ~/.vst.bak, and then copy/move one by one into a brand new and empty ~/.vst directory.
the one-by-one, one-step-at-a-time chore shall include each one of the symlinks under ~/.vst.bak/u-he, of course.
it's a boring to death of a task, i know, but ultimately it will get you to a sane set of VSTs, nevertheless.
concluded that out of 63 vsts in my particular batch, 9 seem to be in direct conflict with the u-he choices. of the 9, 7 are synth-port types. the other 2, an analyser and notch filter. What they all have in common is being built using the Juce format.
conversely, removing the u-he(s) and re-introducing the otherwise problematic nine - all is rosey.
the radium compressor also has a buddy problem, but i'll run that down another day... or week... or month.... or...
re. U-He plugins...
is that a question?
nope. there's no reason whatsoever for the (native linux VST) U-he plug-ins not being available on qtractor v0.8.1.
what are evidences of your affirmation?
byee
re. U-He plugins...
Yeah, no not a question a recent observation.
When attempting to add one of those plugins to a track, typing in the name brings no result. Path to the .vst directory is correct.
Odd behaviour, as i never had the problem before and the plugin loads in previous sessions.
cheers
this from the 'message' window where the plugin is present...
/home/me/Desktop/Protoverb.log
no deskTopFile found
preset=initialize
Trying setUniqueID(1969770582)...
setUniqueID (1969770582)
Saving registration code to /home/me/.u-he/Protoverb/Support/com.u-he.Protoverb.user.txt
failed to open /home/me/.u-he/Protoverb/Support/com.u-he.Protoverb.user.txt to read registration key
HOST 'Qtractor'
API 'VST2'
Starting REVISION 4408
DelayNetWorks random 166.11 after 14277 rounds
Using vector extension SSE3
new instance of AM_PreferencesAudio created for Protoverb # 1
Structure 0 - 5
HW8
Wide
loadPreferences() - Protoverb
void AM_AudioMan::createMidiPrograms()
Preset from 'Protoverb'
Params: press button
AM_DelayNetWorks::setParameterComplex
Structure 0 - 0
HHD
Wide
Seed 0
OMG... need to reseed
DoublettesInRange 0.00
collisionLaw ran 15 tests
No Bridges
stateInfoLevel level back to 0
AM_AudioMan::reset()
getMidiAssignPath(): /support/com.u-he.Protoverb.midiassign.txt
READING midiAssignFile
re. U-He plugins...
Odd behaviour, as i never had the problem before and the plugin loads in previous sessions.
you mean that the plugins, inserted on previously existing sessions files, loads fine? but trying to add a new they just doesn't show up on VST plug-in discovery/selection?
if that's so, try first to backup your ~/.u-he directory, where you installed your U-he plug-ins, and start re-installing one by one from scratch on a new and empty ~/.u-he directory; on each install, test whether the VST discovery process is successful, by showing up on listing, one at a time; if none appears still, then it's some other VST plugin, not from u-he, that is crashing the discovery process too early: you'll have to investigate which one is the culprit, by starting over from ~/.vst contents perhaps.
hth.
cheers
re. U-He plugins...
"you'll have to investigate which one is the culprit, by starting over from ~/.vst contents perhaps."
will give it a go and report back soon-ish.
thanks
cheers
re. U-He plugins...
yep, conflicts with some other plugin. still sifting thru to find the offender.
re. U-He plugins...
maybe, just a suggestion, you can start by backing up
~/.vstto somewhere else, say~/.vst.bak, and then copy/move one by one into a brand new and empty~/.vstdirectory.the one-by-one, one-step-at-a-time chore shall include each one of the symlinks under
~/.vst.bak/u-he, of course.it's a boring to death of a task, i know, but ultimately it will get you to a sane set of VSTs, nevertheless.
hth.
cheers
re. U-He plugins...
"...the one-by-one, one-step-at-a-time chore..."
that's been my course of action. taking my time with long breaks along the way.
getting close. ten more to go.
will report back when i snag the culprit.
toodles
re. U-He plugins... [Solved]
concluded that out of 63 vsts in my particular batch, 9 seem to be in direct conflict with the u-he choices. of the 9, 7 are synth-port types. the other 2, an analyser and notch filter. What they all have in common is being built using the Juce format.
conversely, removing the u-he(s) and re-introducing the otherwise problematic nine - all is rosey.
the radium compressor also has a buddy problem, but i'll run that down another day... or week... or month.... or...
thanks again,
cheers
drumsynth.so - distrho/ports
EasySSP.so - distrho/ports
eqinox.so - distrho/ports
hypercyclic.so - mucoder
NotNotchFilter.so - teragonaudio
Obxd64.so - distrho/ports
tonespace.so - mucoder
tunefish4.so - tunefish-synth
vex.so - distrho/ports
Add new comment