Nicotux
in fact it seems there are really too many instability in the GIT version
It goes on hanging and killing VirtualDJ
I really prefer the old one for now
It goes on hanging and killing VirtualDJ
I really prefer the old one for now
Posted Mon 25 Feb 19 @ 6:24 pm
bluescreen25
Nicotux wrote :
in fact it seems there are really too many instability in the GIT version
It goes on hanging and killing VirtualDJ
I really prefer the old one for now
It goes on hanging and killing VirtualDJ
I really prefer the old one for now
Yes. I tested your old 64bit version from your webspace. Works stable but one bug into.
The path were it writes and reads config and presets is in VDJ Plugins folder, should be the Plugins64 folder. It works with dll in Plugins64 but config in Plugins.
Posted Mon 25 Feb 19 @ 7:21 pm
Nicotux
The old version was rewrited using Forms and are pure Windows where the new one is using cppStep maybe for MAC users
I posted 2 more stable .dll they seems usable but they fails often at freeing memory and sometimes hangs at startup other times it works as expected and there is a network issue: do not activate before the Downloading..." message disapear or give a wrong IP/Host ... otherwise your VDJ is bricked for good
copy/paste and "in config" presets seems to work now ...
I posted 2 more stable .dll they seems usable but they fails often at freeing memory and sometimes hangs at startup other times it works as expected and there is a network issue: do not activate before the Downloading..." message disapear or give a wrong IP/Host ... otherwise your VDJ is bricked for good
copy/paste and "in config" presets seems to work now ...
Posted Mon 25 Feb 19 @ 7:43 pm
darkspr1te
Nicotux wrote :
The old version was rewrited using Forms and are pure Windows where the new one is using cppStep maybe for MAC users
I posted 2 more stable .dll they seems usable but they fails often at freeing memory and sometimes hangs at startup other times it works as expected and there is a network issue: do not activate before the Downloading..." message disapear or give a wrong IP/Host ... otherwise your VDJ is bricked for good
copy/paste and "in config" presets seems to work now ...
I posted 2 more stable .dll they seems usable but they fails often at freeing memory and sometimes hangs at startup other times it works as expected and there is a network issue: do not activate before the Downloading..." message disapear or give a wrong IP/Host ... otherwise your VDJ is bricked for good
copy/paste and "in config" presets seems to work now ...
i'll pull a copy of the git and have a look, how are you asking for heap mem ?
Posted Tue 26 Feb 19 @ 4:56 am
Nicotux
I was not aware there was a special need with heap mem until I got the "Heap mem corruption" message" .
I Did not take a look at cppStep either.
I think for now it may be only related to pointers/Classes wrongly freed/deleted as some were possibly be used before initialization, some may certainly be used once uninitialized either. This is the problem when using threads without sync
As for old version I compiled both again this time without the "config tool" and they both work fine.
Last time I did try an external configuration tool but looks verry instable with presets
badly sources were lost during last windows update 1809
I Did not take a look at cppStep either.
I think for now it may be only related to pointers/Classes wrongly freed/deleted as some were possibly be used before initialization, some may certainly be used once uninitialized either. This is the problem when using threads without sync
As for old version I compiled both again this time without the "config tool" and they both work fine.
Last time I did try an external configuration tool but looks verry instable with presets
badly sources were lost during last windows update 1809
Posted Tue 26 Feb 19 @ 12:58 pm
darkspr1te
Nicotux wrote :
I was not aware there was a special need with heap mem until I got the "Heap mem corruption" message" .
I Did not take a look at cppStep either.
I think for now it may be only related to pointers/Classes wrongly freed/deleted as some were possibly be used before initialization, some may certainly be used once uninitialized either. This is the problem when using threads without sync
As for old version I compiled both again this time without the "config tool" and they both work fine.
Last time I did try an external configuration tool but looks verry instable with presets
badly sources were lost during last windows update 1809
I Did not take a look at cppStep either.
I think for now it may be only related to pointers/Classes wrongly freed/deleted as some were possibly be used before initialization, some may certainly be used once uninitialized either. This is the problem when using threads without sync
As for old version I compiled both again this time without the "config tool" and they both work fine.
Last time I did try an external configuration tool but looks verry instable with presets
badly sources were lost during last windows update 1809
I'am not a windows coder so upfront i'll be honest am here just to learn more, My arm/linux background is more colorful . I'am able to compile and run the newer build from out of box Visual studio community but it's heavy , I need to get up to speed on windows compiler optimizations , I think also we might be compiling in resources we are not using.
I'll put my money where my mouth is this weekend and check on those assumptions.
I am looking at the sources for the OS2L from http://os2l.org/ , while QLC does not support OS2L it's similar and quite optimized. Would it be worth going back to bare bones optimize the plugin, with first few channels being static (all beats, first beat of bar, 3/4, 8 and 16) and leaving the assignment side to QLC+ setup , i will admit that between VDJ and QLC it was confusing as parameter from VDJ would be altered by QLC (on every beat => 4 beat of bar in Duration factor) , I can do some documentation to clear that up as it's not a software issue but documentation/understanding.
I have noticed with my numark nv2 and current and prior builds of the plugin and QLC 4.12.1 that my touch sense is almost lost , if i hold the platter it stops starts it's clear VDJ is lagging. I also get the feeling my pc is slowing down yet cpu usage remains normal, it's more like VDJ starts reacting slower.
That leads me to do we need a bloated config system ? I get why it's there and it was invaluable in me getting my rig up and running. Maybe with proper calls for heap request/release it may fix that , I certainly seen more stability in the new build if i do my config then close VDJ and reload then not touch(open) the config it is more reliable and does not exhibit resource drains (EDIT: as much) .
Could we have a separate plugin for the config/setup side or even a outside app , not sure how the plugin jail works so am just throwing this out there.
Where is the current office git for this plugin? i would like to make some pull requests, documentation updates.
I have already started a guide of DIY from the ground that includes building your own DMX/RGB devices but the initial written stuff is just VDJ+QLC and one cheap DMX device (guide is applicable to Raspberry pi QLC users too) ,Massimo's guides are great but if you want to do just the VDJ and simple light rig then it's information split over dozens of posts and videos, I would rather a one VDJ centric PDF.
I look forward to your feedback
regards
darkspr1te
https://github.com/darkspr1te
Posted Fri 01 Mar 19 @ 11:59 am
Nicotux
It seems "current office git for this plugin" is here: https://github.com/VDJartnet/VDJartnet
I finally created again this QnD configuration tool from scratch, not so difficult and by the way I like this idea of runner only plugin. I won't configure DMX during gigs.
But not havin the possibility to do so may prevent the temptation to completely broke a script by mistake in live
I finally totally rewrite a test plugin of my own and discover there are possible issues with unloading plugins by yourself:
VDJ plugin design needs write access to buttons and sliders values and simply write them back once the class instance was freed .. heap corruption raise
by the way once VDJ wrote the button status, it may call the callback which was also in the freed class ... this time it's access violation
There is / It seems there is no unregister method this is coder's job to take care about it.. as not explain in the missing documentation
" it's more like VDJ starts reacting slower. " :
You're true, it's real VDJ react slower but this is one of the fixed bug in the packet transmission thread - requests to VDJ where extremely fast
"...parameter from VDJ would be altered by QLC ...":
Right once again but ... previous issue related, at least in part, QLC+ was overflowed by art-net packets, would be somehow less now - 1%of previously
Note I have same issues QLC/other -> fixtures related with missing commands when DMX packets are too fast
OS2L & Art-Net i don't think it is the real purpose here, as we don't use Art-Net at all in reality but a verry subset which allows us to transmit raw DMX packets over Eth
There are many more features and possibilities with Full Art-Net to acheive almost the same as OS2L
Windows & Visual Studio and xNix coders ... Raspberry pi &^ Arduino ... and maybe why not VDJ arm version for Windows10 in the Store ?
I finally created again this QnD configuration tool from scratch, not so difficult and by the way I like this idea of runner only plugin. I won't configure DMX during gigs.
But not havin the possibility to do so may prevent the temptation to completely broke a script by mistake in live
I finally totally rewrite a test plugin of my own and discover there are possible issues with unloading plugins by yourself:
VDJ plugin design needs write access to buttons and sliders values and simply write them back once the class instance was freed .. heap corruption raise
by the way once VDJ wrote the button status, it may call the callback which was also in the freed class ... this time it's access violation
There is / It seems there is no unregister method this is coder's job to take care about it.. as not explain in the missing documentation
" it's more like VDJ starts reacting slower. " :
You're true, it's real VDJ react slower but this is one of the fixed bug in the packet transmission thread - requests to VDJ where extremely fast
"...parameter from VDJ would be altered by QLC ...":
Right once again but ... previous issue related, at least in part, QLC+ was overflowed by art-net packets, would be somehow less now - 1%of previously
Note I have same issues QLC/other -> fixtures related with missing commands when DMX packets are too fast
OS2L & Art-Net i don't think it is the real purpose here, as we don't use Art-Net at all in reality but a verry subset which allows us to transmit raw DMX packets over Eth
There are many more features and possibilities with Full Art-Net to acheive almost the same as OS2L
Windows & Visual Studio and xNix coders ... Raspberry pi &^ Arduino ... and maybe why not VDJ arm version for Windows10 in the Store ?
Posted Fri 01 Mar 19 @ 2:20 pm
bluescreen25
@Nicotux :
You did a very good job. I tested all your versions and we are together with our meaning about the last sources of VDJArtnet are not usable.
So lets get our work together to get two stable working 32 and 64bit versions.
Did you test my 32bit package ? https://www.qlcplus.org/forum/download/file.php?id=9669
This package is very stable, did not have any problems with it and you can do all things "on the fly" to test presets and standalone scripts of your choice.
As i scripted many presets with much text, i become the problem that i could not compile the source included the big presets.txt. So i went the way to outsource it with the possibility to load the presets_long.txt with the @p line in VDJArtnet.conf. Thats why in the actually sources on github is a stringlinker included....
The stringlinker does its job, but all other problems are not fixed...
I find out that your 64bit version 07.10.18 237k is stable, too. If you would upload the sources, i would like to make some changes in it, to get same workflow as on my 32bit version. Your 64bit must be placed into Plugins64\Autostart but the VDJArtnet.conf has to be placed into Plugins\Autostart, then my hole package is also usable with your dll. Also your dll has the possibility of config in VDJ, but with two columns (description NAME included) . If i load my VDJArtnet.conf into your dll, it works as expected but the workflow is not the same. Drag and drop presets is not usable ... its not ready, i know.
Two possibilites: Thrinking the config table as in older versions or we make the configs ready in both versions with 2 columns.
Any other idea ?
regards , Ralf
You did a very good job. I tested all your versions and we are together with our meaning about the last sources of VDJArtnet are not usable.
So lets get our work together to get two stable working 32 and 64bit versions.
Did you test my 32bit package ? https://www.qlcplus.org/forum/download/file.php?id=9669
This package is very stable, did not have any problems with it and you can do all things "on the fly" to test presets and standalone scripts of your choice.
As i scripted many presets with much text, i become the problem that i could not compile the source included the big presets.txt. So i went the way to outsource it with the possibility to load the presets_long.txt with the @p line in VDJArtnet.conf. Thats why in the actually sources on github is a stringlinker included....
The stringlinker does its job, but all other problems are not fixed...
I find out that your 64bit version 07.10.18 237k is stable, too. If you would upload the sources, i would like to make some changes in it, to get same workflow as on my 32bit version. Your 64bit must be placed into Plugins64\Autostart but the VDJArtnet.conf has to be placed into Plugins\Autostart, then my hole package is also usable with your dll. Also your dll has the possibility of config in VDJ, but with two columns (description NAME included) . If i load my VDJArtnet.conf into your dll, it works as expected but the workflow is not the same. Drag and drop presets is not usable ... its not ready, i know.
Two possibilites: Thrinking the config table as in older versions or we make the configs ready in both versions with 2 columns.
Any other idea ?
regards , Ralf
Posted Mon 04 Mar 19 @ 11:02 am
Nicotux
There is a .src folder lol they may contains the .bat if you wanna compile manualy 07.10.18 237k may be in OLD they are not so stable: spurious restart of VDJ and exit issue, can't load more than once.... Was stable enough for I use it till I compile 20190227 lite version which this time is solid rock as GUI instability was removed with GUI itself ^^
For now the universe feature works in the base "one universe per interface". when attempt to do "one interface per deck" as presets are global they interfer. Stability issues with 2 config scripts using same port.
No difference in src between 32 and 64 but the "64" at the end of the name as a conditional.Only a new configuration in VS was enough
The funky buttons seems not to be fixable with a base plugin. only Audio and Video and Transition can do
The stability problem seems comes from within VDJ API and a misunderstanding of how it works. any DOC ?
"OnRelease" is not at allways to delete the plugin. It indicates the plugin was no more on a visible slot, which is slightly different as it may go on react in backgroung.
certainly the reason verbs "is_releasefx" and "effect_releaseslider_active" and "effect_releaseslider" exists
Yes I tested the version from QLC forum. It already make VDJ fails to quit properly and takes time to load as well. With a bad network sometimes hangs VDJ/Win,10
the "on the fly" is working well, your 20181208 src have it too. it rocks :)
in fact I removed the use of stringlinker for many reasons.:
I don't want to add another language to VS, not enough space left
I'm not fan with the idea of fixed presets. A so added an external defaultpresets.conf. By the way these scripts need to be reworked
I will need another approch of scripts, the use of universe may need to alter them
Smaller the plugin are ...
The conf file ... it was much easy for tests to keep the same one. I fixed this
The two columns was the first adaptation I did too... my dll would be able to load both config file but prefer the new ones. Yes i never touch to cppStep so far the drag & drop & undo features are as i found them. The goal was to make the engine work... reason of the "_lite" versions
Idea ? yes too many, let's make tthe actual unctionalities work and see later
i.e.:
- name the rows to match the fixtures
- class presets by catedory
- config/preset loader/saver
- banks of config
- plugin command to switch config bank on the fly
- plugin command to load config/config sets on the fly
- plugin command to load preset/presets sets on the fly
- plugin command to switch universe on the fly
- plugin command to change host/port
- plugin command to change fixture sets
- plugin command to apply a preset to a given config line
- vdjartnetSend not enough, make one deck base depending on where the plugin was loaded artnetSend_1
- better universe handling (network/subnet/universe base better than raw value)
...
- A BLACKOUT command
For now the universe feature works in the base "one universe per interface". when attempt to do "one interface per deck" as presets are global they interfer. Stability issues with 2 config scripts using same port.
No difference in src between 32 and 64 but the "64" at the end of the name as a conditional.Only a new configuration in VS was enough
The funky buttons seems not to be fixable with a base plugin. only Audio and Video and Transition can do
The stability problem seems comes from within VDJ API and a misunderstanding of how it works. any DOC ?
"OnRelease" is not at allways to delete the plugin. It indicates the plugin was no more on a visible slot, which is slightly different as it may go on react in backgroung.
certainly the reason verbs "is_releasefx" and "effect_releaseslider_active" and "effect_releaseslider" exists
Yes I tested the version from QLC forum. It already make VDJ fails to quit properly and takes time to load as well. With a bad network sometimes hangs VDJ/Win,10
the "on the fly" is working well, your 20181208 src have it too. it rocks :)
in fact I removed the use of stringlinker for many reasons.:
I don't want to add another language to VS, not enough space left
I'm not fan with the idea of fixed presets. A so added an external defaultpresets.conf. By the way these scripts need to be reworked
I will need another approch of scripts, the use of universe may need to alter them
Smaller the plugin are ...
The conf file ... it was much easy for tests to keep the same one. I fixed this
The two columns was the first adaptation I did too... my dll would be able to load both config file but prefer the new ones. Yes i never touch to cppStep so far the drag & drop & undo features are as i found them. The goal was to make the engine work... reason of the "_lite" versions
Idea ? yes too many, let's make tthe actual unctionalities work and see later
i.e.:
- name the rows to match the fixtures
- class presets by catedory
- config/preset loader/saver
- banks of config
- plugin command to switch config bank on the fly
- plugin command to load config/config sets on the fly
- plugin command to load preset/presets sets on the fly
- plugin command to switch universe on the fly
- plugin command to change host/port
- plugin command to change fixture sets
- plugin command to apply a preset to a given config line
- vdjartnetSend not enough, make one deck base depending on where the plugin was loaded artnetSend_1
- better universe handling (network/subnet/universe base better than raw value)
...
- A BLACKOUT command
Posted Mon 04 Mar 19 @ 2:24 pm
djcel
We are here to help you with the VDJ SDK. Did you have a look to examples provided at the end of this page?
https://www.virtualdj.com/wiki/PluginSDK8.html
https://www.virtualdj.com/wiki/PluginSDK8.html
Posted Mon 04 Mar 19 @ 9:57 pm
Nicotux
@djcel :$ LOL
This plugin was created as a "Basic plugin (with default interface)" ok, we now know buttons will not work.
But sure we can't do what internal plugins can't do either
There is no way to know not only from which deck a button was pushed but from which config interface^^
"get deck" does not help we receive a wrong info and "get_plugindeck" either only work at onload time.
sub instances of the interface seems to somehow work but will not always affect the right effect... see "grab_screen"
a workaround? maybe for now only one interface open at a time. but some internal one can do it specialy "Cover"
Almost all existing plugins are affected but internal soundeffects
Only "Cover" make exception
ALL plugins are affected by the leak of slot info
thus yes help would be welcome as well as an API update
This plugin was created as a "Basic plugin (with default interface)" ok, we now know buttons will not work.
But sure we can't do what internal plugins can't do either
There is no way to know not only from which deck a button was pushed but from which config interface^^
"get deck" does not help we receive a wrong info and "get_plugindeck" either only work at onload time.
sub instances of the interface seems to somehow work but will not always affect the right effect... see "grab_screen"
a workaround? maybe for now only one interface open at a time. but some internal one can do it specialy "Cover"
Almost all existing plugins are affected but internal soundeffects
Only "Cover" make exception
ALL plugins are affected by the leak of slot info
thus yes help would be welcome as well as an API update
Posted Tue 05 Mar 19 @ 12:35 am
bluescreen25
@Nicotux
"Yes I tested the version from QLC forum. It already make VDJ fails to quit properly and takes time to load as well. With a bad network sometimes hangs VDJ/Win,10"
I am confused. This dll is the fastest stable 32bit version with config I tried. Never hanged, takes no time by start and release. Tested on 3 different Notebooks with Win10 and Win 7. I found no delays and no CPU resources needed. I made about 10 Gigs with 6 hours of working without problems...
Yesterday I spent some time to my new backup notebook. Copied the whole package into, changed only the Userfolder in conf. Started VDJ, Config, Drag/Drop the needed presets and it works . Also on the fly testing by overwriting lines by drag other presets worked as expected on QLC+ . I am confused.
Could really network problems in systems be the point ? I use one notebook with VDJ and over network cable to other notebook with QLC+.
I always rename the dlls to right name without ..32 or ..64. This made problems to me if they have not originally name. And only one dll in Autostart folder!
Plugins will also not work well if other dll like soundswitch.dll is in Autostart,too !
"Yes I tested the version from QLC forum. It already make VDJ fails to quit properly and takes time to load as well. With a bad network sometimes hangs VDJ/Win,10"
I am confused. This dll is the fastest stable 32bit version with config I tried. Never hanged, takes no time by start and release. Tested on 3 different Notebooks with Win10 and Win 7. I found no delays and no CPU resources needed. I made about 10 Gigs with 6 hours of working without problems...
Yesterday I spent some time to my new backup notebook. Copied the whole package into, changed only the Userfolder in conf. Started VDJ, Config, Drag/Drop the needed presets and it works . Also on the fly testing by overwriting lines by drag other presets worked as expected on QLC+ . I am confused.
Could really network problems in systems be the point ? I use one notebook with VDJ and over network cable to other notebook with QLC+.
I always rename the dlls to right name without ..32 or ..64. This made problems to me if they have not originally name. And only one dll in Autostart folder!
Plugins will also not work well if other dll like soundswitch.dll is in Autostart,too !
Posted Tue 05 Mar 19 @ 12:16 pm
bluescreen25
Does not make sense what i make in video but you can see how stable it works....
Posted Tue 05 Mar 19 @ 6:33 pm
