Xrns Script Frontend Released

A little request: is it possible to make the XRNS Script Frontend to “remember” the last source and destination files? So that the last used files will show up automatically as default (already be “filled into” the “specify source/destination fields” in advance, but able to change it of course)? It would be convenient.

EDIT: I just noticed that this is already implemented… Stupid me. Sorry!

Well, since I can’t delete this embarrasing post, I’ll just say that this is a really great tool. Especially the XRNS2MID script is extremely useful. Keep up the good work!

Yes, taktik, it would save some time. Much appreciated!

Any posibility to show the user a value in the dropdown and send the script something else?

I have a new “set/unset” flag in xrns_randomizer.php that asks: [Keep Octave? 0 or 1]

It would be cleaner to show [Keep Octave? No or Yes] and send the script 0 or 1.

Something like:

  
options(def:0|No, 1|Yes);  
  

Where | is optionial. This would also solve the Quality level description feature request. It would look something like:

  
options(1|Ghetto, 2, def:3, 4|CD, 5, 6, 7, 8, 9, 10|Without Wires burns Directly from Brain to DVD)  
  

yes, did not dare to ask for it, but I would like it

I’ve noted the request and will update the frontend, when i have more time. Currently all values are passed to the GUI elements directly and also read from, so for this to work i need to additionaly store these in the frontend and do some more code adjustments.

I have plans for a future Java based frontend, but it isn’t that high priority on my list. Concentrating on music currently. :)

I tried this at one point and had a GUI going. No sweat.

However, I spent a day trying to package something that would be easy for a user without PHP5, PASHUA and some required third party tools on OS X, similar to XRNS-SF, and that’s where I failed. :(

Updated to version 1.05:

  • Fixed: Textfields did not restore their last used value.
  • Changed: The options keyword returns now the selected index to the script, instead of the full text.
  • Changed: Updated included FLAC version to 1.2.1.

Thanks for the update.

But, could we have a new keyword instead of changing “options” to send the index? How is the case where actual text needs to be sent to the command prompt handled?

Keep options the way it was. Make a new keyword (options2, or a better keyword) that does exactly what options does now?

Also, where’s the “fixed” IT alien search and replace script?

Thanks!

In the world of command line scripts, a world that is far beyond our project, there are thousands of cases where text would be required.

Eliminating the option of passing words to a CLI in a CLI interface is ignorant. Both options should be available (pass an index, pass a “word”)

There was nothing eleminated, the script can take care of that with nearly no effort. I think it’s perfectly fine now.

<?php <br />  
switch ($argv[1])  
{  
 case 0:  
 case "zero":  
  
 echo "0 was selected";  
 break;  
  
 case 1:  
 case "one":  
  
 echo "1 was selected";  
 break;  
}  
  
?>  
  

This puts the responsibility on the script…

In a more generic case, explain to me how I make a dropdown lists of servers I want to do a ping on?

ping 0
ping 1
ping 2
ping 3

Explain to me how I run a dropdown of sftp [[user@]host[:file [file]]] choices?

sftp 0
sftp 1
sftp 2
sftp 3

Etc, etc, etc. Yes these are not PHP but generic cases over specific cases, please.

Why can’t we have both?

EDIT: I understand the advantage of indexes, and will use them, but eliminating “passing text” to a “command line interface” is short sighted.

No, i’m talking about 12 servers I want in a list of static choices and I don’t want to type them every time.

I’m talking about a generic interface to the CLI, where indexes are unheard of.

Seriously, is keeping both really that difficult?

What?!

No I did not say this!

I like indexes, I think 1.05 with indexes are a big improvement.

In the context of Renoise, thinkg of Distortion ->Distortion2, Filter → Filter2.

All I want is the new feature to not kill the old one, which was concieved as a generic CLI dropdown, and it may come in handy in the future (in fact, all command line scripts except ours expect this behaviour)

Why can’t we have both?

On the command line, there are no dropdowns.

You are mapping the dropdown paradigm to your expectations of what the command line wants based on 10 scripts, vs the thousands of variations where it could be useful.

:)

I’m thinking it’s a lot easier for Beatslaughter to cut & paste “options” and change a few things to “options2”, thus having two ways of doing the same thing, than it is to obsfucate this whole debate into something that takes the CLI Gui into something else.

That’s all.

This isn’t a GUI,

This isn’t a form.

It’s a “Generic CLI Interface” for generic commands found on said interface.

It should be flexible and useful for our purposes, but also flexible for (theoretical use of) commands like cvs, nslookup, ping, grep, pear, flac, oggenc, ps, the list goes on to thousands of commands.

Version 2, the “XRNS ONLY” version could be stricter, but right now you are taking functionality away from a wonderful and well thought out hack that was meant to sit on top of anything found on the command line.

The change was easy to make, that’s why it was made. Otherwise, it would not have happened because, as I understand, Beatslaughter is too busy, and any free time is probably spent on (among a ton of other stuff unrelated to this project) version 2.

PS: I already proposed something similar, well the opposite (your version would be better), on page one of this thread:

http://www.renoise.com/board/index.php?s=&…st&p=100543

It was rejected until version 2 due to time constraints.

Thanks a lot, just checked your changes and it seems fine.

I just checked it and got “Script Execution Failed” popup on exit of all scripts. But the scripts work anyway.

Otherwise, cool, and thank you from the bottom of my heart.

static void RunScript(HWND hwnd)  
{  
 TCHAR szProgDir[MAX_PATH], szPhpExe[MAX_PATH], szUtils[MAX_PATH], szScriptFile[MAX_PATH], szBuffer[BUFFER], szCommandline[BUFFER];  
 STARTUPINFO si;  
 PROCESS_INFORMATION pi;  
  
 GetModuleFileName(ghInstance, szProgDir, DIMOF(szProgDir));  
 PathRemoveFileSpec(szProgDir);  
  
 lstrcpy(szPhpExe, szProgDir);  
 PathAppend(szPhpExe, _T("\\php\\php.exe"));  
  
 lstrcpy(szUtils, szProgDir);  
 PathAppend(szUtils, _T("\\utils"));  
 SetEnvironmentVariable(_T("PATH"), szUtils);  
  
 lstrcpy(szScriptFile, szProgDir);  
 wsprintf(szScriptFile, _T("%s\\scripts\\%s.php"), szProgDir, gCfg.szLastUsedScript);  
  
 iLastUsed = 0;  
 ZeroMemory(szBuffer, DIMOF(szBuffer));  
 if (EnumChildWindows(GetParent(hwnd), BuildCommandline, (LPARAM) szBuffer) == 0)  
 return;  
  
 ZeroMemory(szCommandline, DIMOF(szCommandline));  
 wsprintf(szCommandline, _T(" -n -f \"%s\" -- %s"), szScriptFile, szBuffer);  
  
 INITSTRUCT(si, TRUE);  
 INITSTRUCT(pi, FALSE);  
  
 EnableWindow(GetDlgItem(GetParent(hwnd), IDOK), FALSE);  
 SetCursor(LoadCursor(ghInstance, IDC_WAIT));  
  
 if (CreateProcess(szPhpExe, szCommandline, NULL, NULL, TRUE, (gCfg.fConsole) ? NORMAL_PRIORITY_CLASS|CREATE_NO_WINDOW : NORMAL_PRIORITY_CLASS, NULL, NULL, &si, &pi))  
 {  
 WaitForSingleObject(pi.hProcess, INFINITE);  
  
 EnumChildWindows(GetParent(hwnd), ReloadClipboard, 0);  
  
 CloseHandle(pi.hProcess);  
 CloseHandle(pi.hThread);  
  
 MessageBox(hwnd, _T("Script execution done."), _T("Info"), MB_OK|MB_ICONINFORMATION);  
 }  
 else  
 MessageBox(hwnd, _T("Script execution failed."), _T("Error"), MB_OK|MB_ICONERROR);  
  
 SetCursor(LoadCursor(ghInstance, IDC_ARROW));  
 EnableWindow(GetDlgItem(GetParent(hwnd), IDOK), TRUE);  
}  
  

Edit: Last two lines moved out of if block, or the cursor and window might not get restored, if it fails.

Oh, got what you want now…

  
...  
  
 if (CreateProcess(szPhpExe, szCommandline, NULL, NULL, TRUE, (gCfg.fConsole) ? NORMAL_PRIORITY_CLASS|CREATE_NO_WINDOW : NORMAL_PRIORITY_CLASS, NULL, NULL, &si, &pi))  
 {  
  
 DWORD dwExitCode;  
  
 WaitForSingleObject(pi.hProcess, INFINITE);  
  
 GetExitCodeProcess(pi.hProcess, &dwExitCode);  
  
 ZeroMemory(szBuffer, DIMOF(szBuffer));  
 wsprintf(szBuffer, _T("Script execution done. Exit code: %i"), dwExitCode);  
  
 EnumChildWindows(GetParent(hwnd), ReloadClipboard, 0);  
  
 CloseHandle(pi.hProcess);  
 CloseHandle(pi.hThread);  
  
 MessageBox(hwnd, szBuffer, _T("Info"), MB_OK|MB_ICONINFORMATION);  
 }  
  
...  
  

Yes, not so much a dll, more of an executable (of the /usr/bin/ variety), but:

  • Supporting both PowerPC and Intel requires separate binaries. (afaik)
  • Compiling your own CLI is not trivial
  • Depending on your compile configuration, it can be between 3M to 40M+