Hyakken is the HY dev !

[hyakken]

Tried it ( REAPER 6 ). Same result. Will update my project the hard way then. Hope you can use the feedback.

Reaper issue is "Project Load Warning"?

Can you try this?
Option > Preferences > VST > clear cache/re-scan

Then re-open the project.

Tadashi

[ELEX]

No, that doesn't help ( and I'm not trying that again; it takes forever ). Still getting: "The following effects were in the project file and are not available...", meaning REAPER simply regards the updates as new, different plugins ( as, I understand, did other DAWs ). Surely it's some sort of ID related issue. It's OK, the plugin itself works. I'm gonna stop fiddling with this now and just save presets and replace the plugin in the project manually. Thanks for the help, pity it didn't work.

[hyakken]

I might have used incorrect version number format.
version 1.0.0 was two points format and previous one (1.072) was single point.
This may make some hosts confused.
So I just made v1.0.73 with two points format.
If someone try it, please let me know the result.

https://hy-plugins.com/product/hy-poly/

Tadashi

[] Peter:H []

I might have used incorrect version number format.
version 1.0.0 was two points format and previous one (1.072) was single point.
This may make some hosts confused.
So I just made v1.0.73 with two points format.
If someone try it, please let me know the result.

https://hy-plugins.com/product/hy-poly/

Tadashi

Tried it, does not work. It does not use the 1.0.7x to replace the previous 1.0.0
I have loaded both into VSTHost and opend the info page. It shows different unique IDs. That's probably the reason.
Left is the latest version, to the right is the 1.0.0 Version. Two interesting observations

• both report Version 1000 which probably stands for 1.0.0.0.
• Your latest Version 1.0.73 replaces the version before that without any problem, because the have the same unique ID depicted on the left.

So I have now 3 versions in my VSTHost window, two share the same uniqueID (> 1.0.0) but differ from the uniqueID of version 1.0.0.
Seems like you have to dive into the build process and figure out how to reliably set the uniqueID of the plugin.
I think I should open a software faith healer business with remote diagnosis and voodoo debugging
The next tipp will cost you a drink

[hyakken]

I might have used incorrect version number format.
version 1.0.0 was two points format and previous one (1.072) was single point.
This may make some hosts confused.
So I just made v1.0.73 with two points format.
If someone try it, please let me know the result.

https://hy-plugins.com/product/hy-poly/

Tadashi

Tried it, does not work. It does not use the 1.0.7x to replace the previous 1.0.0
I have loaded both into VSTHost and opend the info page. It shows different unique IDs. That's probably the reason.
Left is the latest version, to the right is the 1.0.0 Version. Two interesting observations

• both report Version 1000 which probably stands for 1.0.0.0.
• Your latest Version 1.0.73 replaces the version before that without any problem, because the have the same unique ID depicted on the left.

So I have now 3 versions in my VSTHost window, two share the same uniqueID (> 1.0.0) but differ from the uniqueID of version 1.0.0.
Seems like you have to dive into the build process and figure out how to reliably set the uniqueID of the plugin.
I think I should open a software faith healer business with remote diagnosis and voodoo debugging
The next tipp will cost you a drink

Thank you for those information.
I will check the uniqueID things.

Tadashi

[] Peter:H []

Thank you for those information.
I will check the uniqueID things.
Tadashi

Tadashi, here's btw two tracks I did with Hy-Poly (free) accompanied by various DAW and free FX, but no other synth.
https://soundcloud.com/p-e-t-e-r-h/hy-a-gressive
https://soundcloud.com/p-e-t-e-r-h/osc1 ... nd-concret

hope you like them
] Peter:H [

[J.Ruegg]

Hi!

I'm wanting to participate in the Kvr OSC with HY-Poly.
But I got some issues with it, looks like it uses a lot of cpu on the background even when I'm not playing any sound.
My DAW (ableton live) GUI starts to become too slugish to work with, playing notes have a delay of 9seconds or so...
And it's weird because the CPU usage in Live shows about 5% when stopped (which is normal) and around 40% when playing my track (again, normal).

But looking on the task manager Live shows always using around 98% CPU. And that's weird, with other plugins I always saw a correlation between what's showed on the live CPU meter and on the task manager.

Any information about this?

I can't work on my track like this

Just to test, I loaded 40 instances of Hy-Poly into an empty project, CPU went up to 100% on taskmanager, and the daw doesn't respond anymore. But everything else works ok...

[z.prime]

A little more info from what @J.Ruegg posted, we both noticed the same thing:

... in Live and Bitwig: very high CPU usage outside the main audio thread! While the CPU meters in the DAW are reporting low CPU usage, a quick look in task manager / activity monitor shows that something is using quite a lot of CPU, even when there is no audio activity. This happens on Mac and Windows in both the aforementioned DAWs but it does not happen on REAPER. I have a suspicion what's going on, will leave that for the end.

To note what we see, with one single instance added a to a Bitwig project, I see these frames across a bunch of threads:

Code: Select all

        35       juce::threadEntryProc(void*)  (in HY-POLY free) + 527  [0x1084c509f]
        34       juce::TimeSliceThread::run()  (in HY-POLY free) + 98  [0x1084b5ef2]
        28       juce::TimeSliceThread::run()  (in HY-POLY free) + 0  [0x1084b5e90]

... 28-35 different threads waiting in these methods. with 10 instances that went up to:

Code: Select all

        275       juce::threadEntryProc(void*)  (in HY-POLY free) + 527  [0x1084c509f]
        274       juce::TimeSliceThread::run()  (in HY-POLY free) + 98  [0x1084b5ef2]

Yikes!

This also correlated to about 150% CPU usage (1.5 cores with the 10 instances, while idle). Unfortunately, it's put a bit of a wrench in my ability to work on a track for the one synth challenge, because even with a high end i9 processor, I'm pretty quickly getting audio spikes and such once I have enough instances added to a project.

I suspect this is due to the way that Bitwig and Live are instructing the plugin to close the GUI, with some sort of "soft" close to make it faster to redisplay when the user clicks on a track.

Anyway, I hope it can be fixed! And, sooner the better!

[hyakken]

Thank you for those info.
I use TimeSliceThread for the animation stuff(modulation meter, filter display etc).
If I disable these animations, those TimeSliceThreads will be eliminated.
I will try it.

Tadashi

[hyakken]

I have removed TimeSliceThreads(except from the oscilloscope fx).
So only the scope fx uses it now(you can avoid to use this fx).
Please try this one.

HY-POLY free v1.0.74 (Win/Mac)
https://drive.google.com/file/d/1u08AIY ... sp=sharing

Tadashi

[hyakken]

Thank you for those information.
I will check the uniqueID things.
Tadashi

Tadashi, here's btw two tracks I did with Hy-Poly (free) accompanied by various DAW and free FX, but no other synth.
https://soundcloud.com/p-e-t-e-r-h/hy-a-gressive
https://soundcloud.com/p-e-t-e-r-h/osc1 ... nd-concret

hope you like them
] Peter:H [

Thank you for your tracks.
I will check it.

Tadashi

[z.prime]

I have removed TimeSliceThreads(except from the oscilloscope fx).
So only the scope fx uses it now(you can avoid to use this fx).
Please try this one.

HY-POLY free v1.0.74 (Win/Mac)

Thanks for the quick turnaround! This is definitely somewhat better -- probably good enough I can try to finish a track for the OSC now - but it still hasn't entirely solved the issue. The existing project I have went from: 580 of these threads to:

Code: Select all

        114       juce::threadEntryProc(void*)  (in HY-POLY free) + 527  [0x10de5220f]
        113       juce::TimeSliceThread::run()  (in HY-POLY free) + 98  [0x10de43062]
        81       juce::TimeSliceThread::run()  (in HY-POLY free) + 0  [0x10de43000]
        73       __gettimeofday  (in libsystem_kernel.dylib) + 0  [0x7fff73b3fe01]

However, to make sure I wasn't using the oscilloscope, I manually opened and closed each instance and usage dropped to:

Code: Select all

        19       juce::WaitableEvent::wait(int) const  (in HY-POLY free) + 133  [0x10de43475]
        18       juce::threadEntryProc(void*)  (in HY-POLY free) + 527  [0x10de5220f]
        17       juce::TimeSliceThread::run()  (in HY-POLY free) + 98  [0x10de43062]

But reloading the project (with no open GUIs, no oscilloscope added) goes back to the 113/114 above. I'll reiterate: this does not seem to happen in REAPER with the same plugin count, so I assume it's something about the order and/or specific calls to the plugin from Bitwig (and presumably Live, too).

Another issue: for some reason, I have to delete the VST/VST3 plugins manually before running the installer, or it doesn't seem to replace them (this has been a problem with all the installers, for me).

Thanks again for the quick look at this issue!

[hyakken]

I have removed TimeSliceThreads(except from the oscilloscope fx).
So only the scope fx uses it now(you can avoid to use this fx).
Please try this one.

HY-POLY free v1.0.74 (Win/Mac)

Thanks for the quick turnaround! This is definitely somewhat better -- probably good enough I can try to finish a track for the OSC now - but it still hasn't entirely solved the issue. The existing project I have went from: 580 of these threads to:

Code: Select all

        114       juce::threadEntryProc(void*)  (in HY-POLY free) + 527  [0x10de5220f]
        113       juce::TimeSliceThread::run()  (in HY-POLY free) + 98  [0x10de43062]
        81       juce::TimeSliceThread::run()  (in HY-POLY free) + 0  [0x10de43000]
        73       __gettimeofday  (in libsystem_kernel.dylib) + 0  [0x7fff73b3fe01]

However, to make sure I wasn't using the oscilloscope, I manually opened and closed each instance and usage dropped to:

Code: Select all

        19       juce::WaitableEvent::wait(int) const  (in HY-POLY free) + 133  [0x10de43475]
        18       juce::threadEntryProc(void*)  (in HY-POLY free) + 527  [0x10de5220f]
        17       juce::TimeSliceThread::run()  (in HY-POLY free) + 98  [0x10de43062]

But reloading the project (with no open GUIs, no oscilloscope added) goes back to the 113/114 above. I'll reiterate: this does not seem to happen in REAPER with the same plugin count, so I assume it's something about the order and/or specific calls to the plugin from Bitwig (and presumably Live, too).

Another issue: for some reason, I have to delete the VST/VST3 plugins manually before running the installer, or it doesn't seem to replace them (this has been a problem with all the installers, for me).

Thanks again for the quick look at this issue!

Thank you for your testing.
I will check this thread thing again.
And I will check the installer too.

Tadashi

Edit:
It seems that the TimeSlicedThread of the oscilloscope starts running even if you don't use it.
I will fix this thing.

[hyakken]

I have removed TimeSliceThreads(except from the oscilloscope fx).
So only the scope fx uses it now(you can avoid to use this fx).
Please try this one.

HY-POLY free v1.0.74 (Win/Mac)

Thanks for the quick turnaround! This is definitely somewhat better -- probably good enough I can try to finish a track for the OSC now - but it still hasn't entirely solved the issue. The existing project I have went from: 580 of these threads to:

Code: Select all

        114       juce::threadEntryProc(void*)  (in HY-POLY free) + 527  [0x10de5220f]
        113       juce::TimeSliceThread::run()  (in HY-POLY free) + 98  [0x10de43062]
        81       juce::TimeSliceThread::run()  (in HY-POLY free) + 0  [0x10de43000]
        73       __gettimeofday  (in libsystem_kernel.dylib) + 0  [0x7fff73b3fe01]

However, to make sure I wasn't using the oscilloscope, I manually opened and closed each instance and usage dropped to:

Code: Select all

        19       juce::WaitableEvent::wait(int) const  (in HY-POLY free) + 133  [0x10de43475]
        18       juce::threadEntryProc(void*)  (in HY-POLY free) + 527  [0x10de5220f]
        17       juce::TimeSliceThread::run()  (in HY-POLY free) + 98  [0x10de43062]

But reloading the project (with no open GUIs, no oscilloscope added) goes back to the 113/114 above. I'll reiterate: this does not seem to happen in REAPER with the same plugin count, so I assume it's something about the order and/or specific calls to the plugin from Bitwig (and presumably Live, too).

Another issue: for some reason, I have to delete the VST/VST3 plugins manually before running the installer, or it doesn't seem to replace them (this has been a problem with all the installers, for me).

Thanks again for the quick look at this issue!

Please try this one.
I tried to optimize the GUI rendering as much as I could.

HY-POLY free v1.0.75(Win/Mac)
https://drive.google.com/file/d/1yN4pSu ... sp=sharing

Tadashi

[z.prime]

Please try this one.
I tried to optimize the GUI rendering as much as I could.
HY-POLY free v1.0.75(Win/Mac)

This is GREAT! Looks like it's solved the issue - I'm only seeing things related to audio processing in the thread list now and CPU usage is way down! Thank you so much for the quick turnaround on this, Tadashi! I'll try to make you proud before end of the month