Hi,
I'm working with some new feature of pdvst~ (https://git.nubegris.com.ar/lucarda/pdvst-0.52/compare/master...sq-fudi) this runs Pd via external scheduler "vstscheduler.dll"
I hit some strange issue with current Pd (Merge branch 'scheduler_fix' 2bea249)
this message no longer works
---------- ; pd dsp 1; ----------
while this one works
[dsp 1( | [s pd]
is not something I changed in pdvst~. Is something that only exhibits with the newest Pd.
I can live with it but may be this is some "peak of iceberg" ?
--
On 24.04.2024 09:45, Lucas Cordiviola wrote:
Hi,
I'm working with some new feature of pdvst~ (https://git.nubegris.com.ar/lucarda/pdvst-0.52/compare/master...sq-fudi) this runs Pd via external scheduler "vstscheduler.dll"
I hit some strange issue with current Pd (Merge branch 'scheduler_fix' 2bea249)
this message no longer works
; pd dsp 1;
while this one works
[dsp 1( | [s pd]
First, what exactly does "not work"? Second, these two message should obviously be equivalent. Are you really sure that they behave differently? If yes, that would be a bug in Pd's message system, not in my scheduler updates.
When I made the updates, I tried not to break the external scheduler mechanism and checked that pd~ still works. Maybe it's an issue in your scheduler implementation? I'll need to have a look at your code, but I'm travelling right now.
is not something I changed in pdvst~. Is something that only exhibits with the newest Pd.
I can live with it but may be this is some "peak of iceberg" ?
--
Ok, no rushing if you are traveling.
First, what exactly does "not work"?
--- ; pd dsp 1; ---
does not start dsp (the toggle in the main Pd window never gets to "on")
Second, these two message should obviously be equivalent. Are you really sure that they behave differently?
yes.
[dsp 1( | [s pd]
works.
If yes, that would be a bug in Pd's message system, not in my scheduler updates.
I could check that the messaging system for other receivers work like [; foo 3( works as expected with [r foo].
When I made the updates, I tried not to break the external scheduler mechanism and checked that pd~ still works.
yes. pd~ still works.
Maybe it's an issue in your scheduler implementation?
nothing changed in pdvst~ scheduler implementation (well yes, but using the unchanged version the issue is still there on current master Pd and not with Pd 0.54-1).
I'll need to have a look at your code, ...
sure: https://git.nubegris.com.ar/lucarda/pdvst-0.52/src/branch/sq-fudi/vst-schedu...
you could also see the "master" branch but as mentioned it also exhibits the issue.
--
Mensaje telepatico asistido por maquinas.
On 24/04/2024 06:40, Christof Ressi wrote:
On 24.04.2024 09:45, Lucas Cordiviola wrote:
Hi,
I'm working with some new feature of pdvst~ (https://git.nubegris.com.ar/lucarda/pdvst-0.52/compare/master...sq-fudi) this runs Pd via external scheduler "vstscheduler.dll"
I hit some strange issue with current Pd (Merge branch 'scheduler_fix' 2bea249)
this message no longer works
; pd dsp 1;
while this one works
[dsp 1( | [s pd]
First, what exactly does "not work"? Second, these two message should obviously be equivalent. Are you really sure that they behave differently? If yes, that would be a bug in Pd's message system, not in my scheduler updates.
When I made the updates, I tried not to break the external scheduler mechanism and checked that pd~ still works. Maybe it's an issue in your scheduler implementation? I'll need to have a look at your code, but I'm travelling right now.
is not something I changed in pdvst~. Is something that only exhibits with the newest Pd.
I can live with it but may be this is some "peak of iceberg" ?
--
Christof,
looking closer this looks like a false alarm.
further testing showed that
[loadbang] | [; pd dsp 1;(
indeed not show dsp toggle ticked but actually dsp is running.
if i do
[; pd dsp 0;(
and then
[; pd dsp 1;(
the toggle shows ticked.
there might be just something in the initial loading. also note this is using the 32bit tcl/tk coming from a normal self built latest Pd.
Sorry for the noise.
--
Mensaje telepatico asistido por maquinas.
On 24/04/2024 07:24, Lucas Cordiviola wrote:
Ok, no rushing if you are traveling.
First, what exactly does "not work"?
; pd dsp 1;
does not start dsp (the toggle in the main Pd window never gets to "on")
Second, these two message should obviously be equivalent. Are you really sure that they behave differently?
yes.
[dsp 1( | [s pd]
works.
If yes, that would be a bug in Pd's message system, not in my scheduler updates.
I could check that the messaging system for other receivers work like [; foo 3( works as expected with [r foo].
When I made the updates, I tried not to break the external scheduler mechanism and checked that pd~ still works.
yes. pd~ still works.
Maybe it's an issue in your scheduler implementation?
nothing changed in pdvst~ scheduler implementation (well yes, but using the unchanged version the issue is still there on current master Pd and not with Pd 0.54-1).
I'll need to have a look at your code, ...
sure: https://git.nubegris.com.ar/lucarda/pdvst-0.52/src/branch/sq-fudi/vst-schedu...
you could also see the "master" branch but as mentioned it also exhibits the issue.
--
Mensaje telepatico asistido por maquinas.
On 24/04/2024 06:40, Christof Ressi wrote:
On 24.04.2024 09:45, Lucas Cordiviola wrote:
Hi,
I'm working with some new feature of pdvst~ (https://git.nubegris.com.ar/lucarda/pdvst-0.52/compare/master...sq-fudi) this runs Pd via external scheduler "vstscheduler.dll"
I hit some strange issue with current Pd (Merge branch 'scheduler_fix' 2bea249)
this message no longer works
; pd dsp 1;
while this one works
[dsp 1( | [s pd]
First, what exactly does "not work"? Second, these two message should obviously be equivalent. Are you really sure that they behave differently? If yes, that would be a bug in Pd's message system, not in my scheduler updates.
When I made the updates, I tried not to break the external scheduler mechanism and checked that pd~ still works. Maybe it's an issue in your scheduler implementation? I'll need to have a look at your code, but I'm travelling right now.
is not something I changed in pdvst~. Is something that only exhibits with the newest Pd.
I can live with it but may be this is some "peak of iceberg" ?
--
Thanks for restoring my sanity :)
On 24.04.2024 14:24, Lucas Cordiviola wrote:
Christof,
looking closer this looks like a false alarm.
further testing showed that
[loadbang] | [; pd dsp 1;(
indeed not show dsp toggle ticked but actually dsp is running.
if i do
[; pd dsp 0;(
and then
[; pd dsp 1;(
the toggle shows ticked.
there might be just something in the initial loading. also note this is using the 32bit tcl/tk coming from a normal self built latest Pd.
Sorry for the noise.
--
Mensaje telepatico asistido por maquinas.
On 24/04/2024 07:24, Lucas Cordiviola wrote:
Ok, no rushing if you are traveling.
First, what exactly does "not work"?
; pd dsp 1;
does not start dsp (the toggle in the main Pd window never gets to "on")
Second, these two message should obviously be equivalent. Are you really sure that they behave differently?
yes.
[dsp 1( | [s pd]
works.
If yes, that would be a bug in Pd's message system, not in my scheduler updates.
I could check that the messaging system for other receivers work like [; foo 3( works as expected with [r foo].
When I made the updates, I tried not to break the external scheduler mechanism and checked that pd~ still works.
yes. pd~ still works.
Maybe it's an issue in your scheduler implementation?
nothing changed in pdvst~ scheduler implementation (well yes, but using the unchanged version the issue is still there on current master Pd and not with Pd 0.54-1).
I'll need to have a look at your code, ...
sure: https://git.nubegris.com.ar/lucarda/pdvst-0.52/src/branch/sq-fudi/vst-schedu...
you could also see the "master" branch but as mentioned it also exhibits the issue.
--
Mensaje telepatico asistido por maquinas.
On 24/04/2024 06:40, Christof Ressi wrote:
On 24.04.2024 09:45, Lucas Cordiviola wrote:
Hi,
I'm working with some new feature of pdvst~ (https://git.nubegris.com.ar/lucarda/pdvst-0.52/compare/master...sq-fudi) this runs Pd via external scheduler "vstscheduler.dll"
I hit some strange issue with current Pd (Merge branch 'scheduler_fix' 2bea249)
this message no longer works
; pd dsp 1;
while this one works
[dsp 1( | [s pd]
First, what exactly does "not work"? Second, these two message should obviously be equivalent. Are you really sure that they behave differently? If yes, that would be a bug in Pd's message system, not in my scheduler updates.
When I made the updates, I tried not to break the external scheduler mechanism and checked that pd~ still works. Maybe it's an issue in your scheduler implementation? I'll need to have a look at your code, but I'm travelling right now.
is not something I changed in pdvst~. Is something that only exhibits with the newest Pd.
I can live with it but may be this is some "peak of iceberg" ?
--
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On 25.04.2024 17:41, IOhannes m zmoelnig wrote:
On 4/25/24 16:24, Christof Ressi wrote:
Thanks for restoring my sanity :)
however, there *is* a regression, as the DSP toggle is not turned on if the DSP is started with loadbang.
Yes, but that one is not related to my scheduler updates. Anyway, I have pushed a fix to develop.
confirmed on my Debian box (jack)
gasdrm IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Thanks for the update Christof!!!
it turns that reporting the patch about the current vst preset the host is using on initial loading *only* works with the updated scheduler.
:)
--
Mensaje telepatico asistido por maquinas.
On 26/04/2024 22:41, Christof Ressi wrote:
On 25.04.2024 17:41, IOhannes m zmoelnig wrote:
On 4/25/24 16:24, Christof Ressi wrote:
Thanks for restoring my sanity :)
however, there *is* a regression, as the DSP toggle is not turned on if the DSP is started with loadbang.
Yes, but that one is not related to my scheduler updates. Anyway, I have pushed a fix to develop.
confirmed on my Debian box (jack)
gasdrm IOhannes
-
Christof Ressi -
IOhannes m zmoelnig -
Lucas Cordiviola