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
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
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"
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.
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
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.
"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
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.
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.
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.
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
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.
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