Hello !!!
plz make this script for font size changing
3312 
THNX!!!
it’s already there, in the options dialog
i want this bending on the keys
hahahahahahha
cool:-)
Hahaha, on a more serious note, is this option accessible through the API?
No.
No and i consider that a stupid option.
Theme customisation should remain a user thing and should never be incorporated into the API. For me that is all the 2 cents i have for this.
im working on a script that assigns a midi knob to a different midi knob by turning a midi knob
strange position
Sorry, I didn’t mean to offend. Incorporating theme customization into the API does not change it’s purpose. It’s still a user thing. But would be aided with 3rd party tools, such as keybindings for the font size. Other ideas for theme customization could be theme automators, based on for example song data; like the AutoColor tool, which happens to mess around with theme customization (although song specific theme customization; that is available via the API). I could see use in theme randomizers too and theme simplifiers for easy color selection and theme generation.
But if “it should never be incorporated into the API”. Fine by me, I don’t agree but I’m not much into UI cosmetics anyway.
Don’t worry, that’s not up to me to decide (i’m still not a core developer 
) but i do share my honest opinion about it.
I am more willing to discuss about how the UI layout can be improved or how the current theme customisation can be improved or extended if the current layout doesn’t work out correctly but with visual aid objects it will always be a delight for one and hell for the other. (not yet even talking about seeying-impaired people). Themes always remain a personal thing and if you are messing with the fixations by making stuff dynamically depending on song-assets, you shoot the stars out of the sky that guide others, which makes navigation quite a bit harder. But that is how i see it.It comes with risks.
I agree that theme selectors/browsers “will always be a delight for one and hell for the other” because we all use different workflows. But I thought that was kind of the point with tools, you install the tools you want (that suit your workflow) and leave the rest. Tools supply you with features that are too specific to be incorporated in the core application. This way we can customize Renoise to have the workflow we want without obstructing other peoples workflow.
Of course these tools could be badly made, obtrusive and destroying your themes without notice. But that is the risk of any API feature, I can see far more damaging effects of current API features such as destroying song data if you misunderstand a tool’s intent.
That being said I think theme customization should be included in the API to solve the issue that “no one solution suits all users”. More discussion about how the UI layout/theme customization can be improved would result in worse features for another workflow. There is no correct solution if there are multiple approaches.
I also think the core developers are better of reducing focus on cosmetics as these are user based preferences and the most powerful tool of the user happens to be the API. This is actually my reason for having a strong opinion on the subject, I want to see Renoise develop as an application rather then having lots of mini-cosmetics. Even simple features like adding a keybinding to the font size take time, why should the core developers waste theirs when this could easily be solved by the community?
Well anyway, that’s my honest opinion, my 2 cents. I appreciate your opinion and all discussion is good. The Renoise developers also seem to allocate their time very well as Renoise is an awesome application. So I have no worries.
Wait a minute, i seem not to be completely awake, if everybody here means changing theme aspects for the tools, then i have misunderstood everone (I had suggested to allow custom skinning myself some time earlier).
I looked at the question and interpreted this was about using tools to change the main Renoise theme-properties which i consider pointless.
For destroying song data we always have undo to save us. The only area where a tool-developer can mess up regarding destroying data structures is afaik only with the sample undo. (specific API calls have to be used to bounce data to undo buffers and if these aren’t done, data is lost) or if they want to do intensional harm, delete song files.
No, sorry for confusing, you had it right the first time. I was talking about changing the main Renoise theme-properties. My point is that if you would use a tool to help you skin Renoise, then you are using a tool that you chose to download and use (no one is forcing people to use tools). Pointless or not, it would certainly allow for solving the original question of this post.
Well, undo is good. But it’s just a first line of safety. What if I fill the undo queue? Or use io calls to manipulate data on the disk, is that undoable? – My point here was that in the end we must trust tool developers to do healthy tools. But of course guiding them in the right direction is good as well as failsafe solutions such as undo.
I wouldn’t mind better API access to undo as well. Allowing tools to modify the undo stack by themselves could provide a lot of good workflow concepts, such as allowing tools to push their own undoable changes (example: If I change a slider in JX Programmer I can not undo the change, the original setting is lost). But that would be a different topic and perhaps a lot of work for little gain, as there are other things more interesting on the wishlist. Undo is not a security measure for failed tools. It is a failsafe for the users actions, in case he makes a misstake.
Even more specifically Font Size (just read the thread title.)
So you have somebody who uses a laptop. When on the move using the built in screen, which may be small (let’s say it’s a 15") but at home has a nice 32" monitor. Every time they go from home to mobile to home to mobile they find themselves having to go into Preferences and change Font Size to make it more usable on the particular screen.
Do you really think them being able to code a little script which will toggle between their two favoured settings with a key combination is that bad an idea? I personally don’t see how it could be harmful in any way.
its very userfulll for netbooks
No that situation doesn’t sound harmful.
But you still don’t really need API for that kind of situation; Every OS has some kind of console scripting option to perform a simple copy operation (you need to specific config.xml copies of which each has their respective settings for the screen size you want to use) and then simply create two shortcuts each having their own first parameter and respective name.
From the back of my head, what one could stuff in a “start_renoise.cmd” file on Windows:
IF %1% == "LARGEFONT" GOTO LARGEFONT
IF %1% == "SMALLFONT" GOTO SMALLFONT
:LARGEFONT
copy [path_to_your_large_font_config_file]\configlarge.xml [path_to_renoise_config]\config.xml
goto START_RENOISE
:SMALLFONT
copy [path_to_your_small_font_config_file]\configsmall.xml [path_to_renoise_config]\config.xml
:START_RENOISE
[path_to_renoiseexecutable]\renoise
I believe a few folks are using this solution already because a similar question to support multiple configs for this purpose has been asked before in the past.
And this trick above you can already do now 
and mac plz