Page 2 of 3

Re: CLI screen position parameters

PostPosted: January 4th, 2014, 9:44 pm
by deema
Cliff Cawley Wrote:I've added support for this in Build 155.

Command line options are as follows:
/SetMainPlayerPos=x,y
/SetPlaylistPos=x,y
/SetEqualizerPos=x,y
/SetLibraryPos=x,y
/SetVisualisationPos=x,y
/SetMainPlayerScale=percentage

Cliff :)



WHAT?!?!?!?!?!?!??!?!! You ROCK! Thank you!!! Testing NOWWWWWWWWWWWWWWWWWWWWWW

Re: CLI screen position parameters

PostPosted: January 4th, 2014, 9:46 pm
by deema
Cliff Cawley Wrote:I've added support for this in Build 155.

Command line options are as follows:
/SetMainPlayerPos=x,y
/SetPlaylistPos=x,y
/SetEqualizerPos=x,y
/SetLibraryPos=x,y
/SetVisualisationPos=x,y
/SetMainPlayerScale=percentage

Cliff :)



Edit - Hahahah, getting a little ahead of myself. I suppose I can wait until build 155 is released. Thanks again, I am super excited

Re: [Added: 155] CLI screen position parameters

PostPosted: January 4th, 2014, 11:02 pm
by deema
Well, while I am at it, I will pose another question/request. A windowless/borderless spectrum analyzer/eq. I assume that if playlists are photoshop made, then they support full alpha channel across their pixel range? Maybe the eq is or can easily be done, too? The reason is the same as the other, to be able to seamlessly integrate the other components into any desktop, as with the player, itself. A border and/or a window put handcuffs on the possibilities right out the gate, as they cannot be fitted into "anything" But without the borders/windows those components can be "anything" and therefore, fit into "anything"

Re: [Added: 155] CLI screen position parameters

PostPosted: January 4th, 2014, 11:46 pm
by Cliff Cawley
deema Wrote:Well, while I am at it, I will pose another question/request. A windowless/borderless spectrum analyzer/eq.


There are several ways to achieve this.

1) You can use the existing Visualisation Window (Right Click->Visualisation) and double click it to toggle the title bar. Still leaves the border so you can resize. Very simple if slightly ugly.

2) Create a skin with just a visualisation layer, which will render everything you see in the above window, into the skin window meaning you can completely remove the border or add whatever else you need to.

3) Create a skin with your own custom visualisation layers. You have a huge amount of control over creating your own custom visualisations this way.

deema Wrote:I assume that if playlists are photoshop made, then they support full alpha channel across their pixel range? Maybe the eq is or can easily be done, too? The reason is the same as the other, to be able to seamlessly integrate the other components into any desktop, as with the player, itself. A border and/or a window put handcuffs on the possibilities right out the gate, as they cannot be fitted into "anything" But without the borders/windows those components can be "anything" and therefore, fit into "anything"


Correct, full alpha support.

There's already a separate skinnable Equalizer window too. Right click on Xion, choose 'Equalizer' to toggle.

Cliff :)

Re: [Added: 155] CLI screen position parameters

PostPosted: January 6th, 2014, 12:07 am
by deema
That is all great new, thanks again, Cliff

Re: [Added: 155] CLI screen position parameters

PostPosted: January 8th, 2014, 10:51 am
by deema
appdata/roaming has some nice config settings, any other folder paths holding config data? And what are .xst files? "States" of the specific players configuration settings, as the folder name suggests? Are these text data that can be edited, is that how the cli will work? Possible to be clicked within windows and have the settings and such occur, bypassing the "need" for the cli, at times? (just lookin at every angle. CLI requires typing settings into script. The xst appears to already hold that data by visual manual placement, similar to splicons (one of the image types in Splindy).

And I just realized that the custom made spectrums are not the "actual" analyzer, not the entity, and so this command /SetVisualisationPos=x,y, will not work for the custom ones, right? And the CLI option will only position the player, is that correct? And this command, /SetMainPlayerPos=x,y, will be associated with both the player and the custom analyzer. So I will need to position the analyzer prior, in PS, to be in the right spot, yes? How will it affect resource utilization if the player and spectrum are on a image canvass that is up to screen sized, potentially up to 1800x900+? And there is no way to have the spectrum in a separate psd, right? Or can it be in say the playlist or EQ psd? I will test this right now but posing question anyway

Re: [Added: 155] CLI screen position parameters

PostPosted: January 8th, 2014, 9:46 pm
by Cliff Cawley
deema Wrote:appdata/roaming has some nice config settings, any other folder paths holding config data?


Settings.dat has all the user settings.

deema Wrote:And what are .xst files? "States" of the specific players configuration settings, as the folder name suggests?


Xst are interface state files. They store anything that a skinner marked with the save_state keyword. Things like last frame that the animation was on.

deema Wrote:Are these text data that can be edited, is that how the cli will work? Possible to be clicked within windows and have the settings and such occur, bypassing the "need" for the cli, at times? (just lookin at every angle. CLI requires typing settings into script. The xst appears to already hold that data by visual manual placement, similar to splicons (one of the image types in Splindy).


.xst files. I'd just go with using the CLI.

deema Wrote:And I just realized that the custom made spectrums are not the "actual" analyzer, not the entity, and so this command /SetVisualisationPos=x,y, will not work for the custom ones, right? And the CLI option will only position the player, is that correct? And this command, /SetMainPlayerPos=x,y, will be associated with both the player and the custom analyzer. So I will need to position the analyzer prior, in PS, to be in the right spot, yes? How will it affect resource utilization if the player and spectrum are on a image canvass that is up to screen sized, potentially up to 1800x900+? And there is no way to have the spectrum in a separate psd, right? Or can it be in say the playlist or EQ psd? I will test this right now but posing question anyway


Correct, /SetVisualisationPos=x,y is just for the built in vis window. Usually people create a section on the main, playlist or equalizer windows to show the visualisation.

It might be possible to use a 1800x900 skin, as long as you're using transparent pixels in between. Otherwise the memory consumption and software rendering won't keep treat users well.

Feel free to give it a try though, I'm not entirely sure what you're trying to do.

Re: [Added: 155] CLI screen position parameters

PostPosted: January 9th, 2014, 3:21 am
by deema
"It might be possible to use a 1800x900 skin, as long as you're using transparent pixels in between. Otherwise the memory consumption and software rendering won't keep treat users well."

With Flash and Splinter, the opposite is true. Alpha channel pixels use more memory than fully opaque RGB. Anyway, hopefully it won't be a problem. Splinter, Flash, and Xion may all be running on any wallpaper at any time, I will streamline it all as much as possible. Should work out fine, I think. This release will have several versions, anyway, for differing computer performances.

EDIT - but, also, I am unclear on the availability of using the EQ or playlist skin for the visualisation layer. Is this possible or is it only coded into the main player? I tried with both and didn't seem to work but that doesn't mean it can't, I could have done it wrong

Re: [Added: 155] CLI screen position parameters

PostPosted: January 9th, 2014, 9:00 am
by logokas
One other thing to note is that you may need to softlock the position of all the elements so that the user doesn't accidentally move the player out of position. This will either require you to remove moveable tags from all the layers when you're ready, or Cliff could put in a CLI command to ignore them manually.

Re: [Added: 155] CLI screen position parameters

PostPosted: January 9th, 2014, 4:26 pm
by Cliff Cawley
deema Wrote:EDIT - but, also, I am unclear on the availability of using the EQ or playlist skin for the visualisation layer. Is this possible or is it only coded into the main player? I tried with both and didn't seem to work but that doesn't mean it can't, I could have done it wrong


You can add a visualisation layer to the Main, EQ or playlist windows, it shouldn't make a difference.

Re: [Added: 155] CLI screen position parameters

PostPosted: January 10th, 2014, 2:19 am
by deema
logokas Wrote:One other thing to note is that you may need to softlock the position of all the elements so that the user doesn't accidentally move the player out of position. This will either require you to remove moveable tags from all the layers when you're ready, or Cliff could put in a CLI command to ignore them manually.


Thanks. This shouldn't be necessary, however, as every time an end user gets taken to a one of the pages(wallpapers), a script will auto set the player and spectrum's positions using the CLI commands that Cliff has/is/will implement(ed)(ing).

But on this softlock subject, is the "soft" part simply the removing of the keywords, kind of a band-aid type fix you are suggesting, yes? Would this work for each skin separately? I was under the impression that where one player is, currently, all will be. So a lock of any kind wouldnt work at all, as every page will/does have a custom placed playa.

Re: [Added: 155] CLI screen position parameters

PostPosted: January 10th, 2014, 4:21 am
by regener8ed
Cliff Cawley Wrote:You can add a visualisation layer to the Main, EQ or playlist windows, it shouldn't make a difference.


could make a difference if he expects it to scale on command.

Re: [Added: 155] CLI screen position parameters

PostPosted: January 10th, 2014, 7:07 am
by deema
regener8ed Wrote:
Cliff Cawley Wrote:You can add a visualisation layer to the Main, EQ or playlist windows, it shouldn't make a difference.


could make a difference if he expects it to scale on command.



Good point. However, I am thinking that the EQ's do not scale with the rest of the player so if I set the size accurately initially, these particular spectrums shouldn't need to be scaled. I'm NOT sure I am right about this but seems it has been my experience

Re: [Added: 155] CLI screen position parameters

PostPosted: January 10th, 2014, 11:51 pm
by logokas
deema Wrote:
logokas Wrote:One other thing to note is that you may need to softlock the position of all the elements so that the user doesn't accidentally move the player out of position. This will either require you to remove moveable tags from all the layers when you're ready, or Cliff could put in a CLI command to ignore them manually.


Thanks. This shouldn't be necessary, however, as every time an end user gets taken to a one of the pages(wallpapers), a script will auto set the player and spectrum's positions using the CLI commands that Cliff has/is/will implement(ed)(ing).

But on this softlock subject, is the "soft" part simply the removing of the keywords, kind of a band-aid type fix you are suggesting, yes? Would this work for each skin separately? I was under the impression that where one player is, currently, all will be. So a lock of any kind wouldnt work at all, as every page will/does have a custom placed playa.


In the current public release version, if a skin has moveable layers, they can be moved. That is the only criteria by which they can be repositioned. However, your Splinterface will want the skin to remain where you want it to be, so as such, it is not desirable for the skins to be moved, as it would break the entire design if the skin is suddenly moved out of place. And since there is no setting that disables moving the player around, there is a chance that users will accidentally do it, one way or the other. Hence, as a current workaround, every skin you want to use, you will have to remove moveable keywords from all layers for every used skin, so that they cannot be moved out of place.

Re: [Added: 155] CLI screen position parameters

PostPosted: January 11th, 2014, 12:36 am
by deema
logokas Wrote:
deema Wrote:
logokas Wrote:One other thing to note is that you may need to softlock the position of all the elements so that the user doesn't accidentally move the player out of position. This will either require you to remove moveable tags from all the layers when you're ready, or Cliff could put in a CLI command to ignore them manually.


Thanks. This shouldn't be necessary, however, as every time an end user gets taken to a one of the pages(wallpapers), a script will auto set the player and spectrum's positions using the CLI commands that Cliff has/is/will implement(ed)(ing).

But on this softlock subject, is the "soft" part simply the removing of the keywords, kind of a band-aid type fix you are suggesting, yes? Would this work for each skin separately? I was under the impression that where one player is, currently, all will be. So a lock of any kind wouldnt work at all, as every page will/does have a custom placed playa.


In the current public release version, if a skin has moveable layers, they can be moved. That is the only criteria by which they can be repositioned. However, your Splinterface will want the skin to remain where you want it to be, so as such, it is not desirable for the skins to be moved, as it would break the entire design if the skin is suddenly moved out of place. And since there is no setting that disables moving the player around, there is a chance that users will accidentally do it, one way or the other. Hence, as a current workaround, every skin you want to use, you will have to remove moveable keywords from all layers for every used skin, so that they cannot be moved out of place.

Yeah, actually, I'm not going to remove the layer for most of them. Nite that I have set up several directions on playlist and eq layer s. It isnt as big a deal. While it is true that I am se tting them up according to how I think it best looks, the entire train for splinters existence is for unequaled customization and aces for the end user. And I have no denials that I am a mediocre artist at best and that I would handcuff everyone by making it my way or no way. I will likely end up just leaving a moveable layer in some standard location for all players. No tine to put in separate thread but makibg mono output does not change cpu utilization, which is at about 7%- on a skin with four animated speakers and a spectrum. Nm about multiple instances either. No need with other skins sets being able to hold vis layer. From phone excuse Missouri's... hahhaha.. misspellings, that is