Fruit
Hi team,
Dunno if it has been reported, apologies.
Almost each time I launch VDJ and I load a first song on a fresh deck I get this as a songpos :
Instead of this :
Dunno if it has been reported, apologies.
Almost each time I launch VDJ and I load a first song on a fresh deck I get this as a songpos :
Instead of this :
Posted Sat 12 Nov 16 @ 4:22 am
djdad
You get the same with the default skin ?
Was this happening with older builds as well ? Can you roll back a few builds back and check ?
Was this happening with older builds as well ? Can you roll back a few builds back and check ?
Posted Sat 12 Nov 16 @ 9:11 am
Fruit
I saw that particular kind of wave drawing sporadically in the past, very rarely though.
It seems I can't reproduce with default skin (not meaning it can't happen).
I rolled back to 3493, 3471, and 3398. Same behavior in all builds I can reproduce this at almost each vdj startup, but not EVERYtime.
This is happening with whatever song, in whatever deck.
Now, I can reproduce this in only ONE layout of my skin showing a pretty big songpos (width="840" height="120"), althought I can't reproduce it in the 'automix' layout wich have an even bigger songpos... The size is the only thing that's uncommon with this songpos I can't seem to think of any other special thing to say about it...
Also I noticed that once it happened, it will reflect in all panels / layouts / other songpos in the skin.
I'll investigate further and check the code again to determine if it could be skin-related.
It seems I can't reproduce with default skin (not meaning it can't happen).
I rolled back to 3493, 3471, and 3398. Same behavior in all builds I can reproduce this at almost each vdj startup, but not EVERYtime.
This is happening with whatever song, in whatever deck.
Now, I can reproduce this in only ONE layout of my skin showing a pretty big songpos (width="840" height="120"), althought I can't reproduce it in the 'automix' layout wich have an even bigger songpos... The size is the only thing that's uncommon with this songpos I can't seem to think of any other special thing to say about it...
Also I noticed that once it happened, it will reflect in all panels / layouts / other songpos in the skin.
I'll investigate further and check the code again to determine if it could be skin-related.
Posted Sat 12 Nov 16 @ 3:11 pm
Adion
Do you have some visibility on the songpos or a panel they are in that makes them invisible when no song is loaded?
That would prevent vdj from knowing the best size to calculate the waveform in, and the optimal size would only be known after it was shown, and thus applied only for the next song.
That would prevent vdj from knowing the best size to calculate the waveform in, and the optimal size would only be known after it was shown, and thus applied only for the next song.
Posted Sat 12 Nov 16 @ 4:03 pm
Fruit
Yes !
<panel visibility="loaded">
<songpos class="songpos4" visibility="var 'xxx' 0"><size width="840" height="120"/><pos x="+100" y="+78"/><cues><size width="11" height="120"/></cues></songpos>
...
</panel>
Posted Sat 12 Nov 16 @ 6:31 pm
Adion
The default resolution should still be 512 pixels though, and it looks like the picture you showed has an even lower resolution.
Is there some tiny songpos somewhere else too?
Is there some tiny songpos somewhere else too?
Posted Sun 13 Nov 16 @ 5:37 am
Fruit
Yes ! In another layout I have this :
Dang ! I made all the mistakes hahahaha :)
<songpos class="songpos">
<pos x="20" y="+82"/>
<size width="150" height="35"/>
<cues><size height="35"/></cues>
</songpos>
Dang ! I made all the mistakes hahahaha :)
Posted Sun 13 Nov 16 @ 6:18 am
Fruit
I sent you a PM.
Posted Sun 13 Nov 16 @ 6:26 am
Adion
You could probably hide the small songpos in the same way as the big one, that way the first load would at least get 500 pixels of resolution
Posted Sun 13 Nov 16 @ 7:23 am
Fruit
I tried but unfortunately it didn't help dunno why... I'll try to find a workaround now that I'm aware of the cause.
Thanks ^^
Thanks ^^
Posted Mon 14 Nov 16 @ 11:31 pm
Fruit
Ok I managed to get something better but not in a convenient way... I put this :
At the very begining of the skin's xml.
The height and width are the highest values found in the whole xml. The y pos +3000 is just here to hide the widget by adding a huge offset. Just an invisible generic songpos. This is not really a proper solution, I must say, it's the first time I have draw something off the window... but it seems to work.
"Seems" to work because after doing some tests with this hidden songpos, I realized that the songpos is trying to also adapt its size according to the skin's size (stretching). So if I load a fresh song on a fresh deck at startup AND the window is stretched to its minimum size, and then I choose the fullscreen mode, the same kind of resizing problems still show (more slightly than before, but stills).
So I decided to grow the width, and then it seems to show correctly everywhere :
There's something odd with this songpos size calculation...
<songpos class="songpos4"><size width="1828" height="120"/><pos x="+35" y="+3000"/></songpos>
At the very begining of the skin's xml.
The height and width are the highest values found in the whole xml. The y pos +3000 is just here to hide the widget by adding a huge offset. Just an invisible generic songpos. This is not really a proper solution, I must say, it's the first time I have draw something off the window... but it seems to work.
"Seems" to work because after doing some tests with this hidden songpos, I realized that the songpos is trying to also adapt its size according to the skin's size (stretching). So if I load a fresh song on a fresh deck at startup AND the window is stretched to its minimum size, and then I choose the fullscreen mode, the same kind of resizing problems still show (more slightly than before, but stills).
So I decided to grow the width, and then it seems to show correctly everywhere :
<songpos class="songpos4"><size width="4000" height="120"/><pos x="+35" y="+3000"/></songpos>
There's something odd with this songpos size calculation...
Posted Thu 17 Nov 16 @ 6:59 pm