actually a bunch also need length in seconds I think, although sometimes it is not clear at all from the documentation . Will insert the new length parameter and see what happens, or maybe if I suspect it to be seconds, can I put in âlength*1000â or something?
No hassle will go through them and check.
Was wondering if we can make variations of certain parameters, for example have an extra slider for the same parameter, but with values linked to the current set bpm. For example the vibrato, tremolo and sweeping filter processes have a frequency slider. Would be cool to have a frequency slider that locks / jumps through beat-synced values according to the bpm in the song. This way you can generate modulations that sync up with the tempo.
Also Iâve come across parameters that need specific values, like 32, 64, 128 ⌠1024, 8192, I think if the spectral stuff is going to be tackled youâll come across these often. How would I have a slider go through specific values, if possible at all right now?
Yeah that would do it and is probably the best way I reckon, I think it would be neater than having length_s and length_ms, but Iâm open to suggestion.
Would something like a snap checkbox and popup for parameters work? So you could select it and then choose from a bunch of preset snap values? Interesting idea, Iâll think about this a bit more.
You could do this by putting the values in a table and then having a popup selector instead of a slider, so instead of using âminâ or âmaxâ in a definition you could have:
set = {32, 64, 128, 1024, 8192}
This would then display a popup instead, if you think that could work then I will add this as an option to the next update.
Works good enough (would multiplying length with 0,001 instead of dividing with 1000 make any difference computationally?)
Sounds good, anything that translates the frequency value to divisions that correspond to the tracks tempo would be nice (similar to how the repeater device has snaps to 1/1, 1/2, 1/8, 1/16D, 1/32T et cetera).
yes please
Also, for a future future update, after the girlfriend is well taken care off , please consider some kind of snapshot system for the parameters. Some kind of preset system which stores set values. This as most processes are pretty particular, anal about when they want to work. Right now I try to update the definitions using "def = " for useful settings, but am I right that floating point defâs between 0 and 1, like 0,5 arenât remembered?
In my last definition file, in my entry for grainex extend, the def setting for parameter trof isnât recalled.
have updated my last definitions + have updated my older stuff as well (note; not your filter definitions) and put all in the attached file, âŚ
âŚmost stuff should work better now⌠still some stuff that doesnât work in the bottom of the list. I think that the reverbs crash because I have to specify a mode, while they donât accept this.
Attachment 4962 not found.
edit;
would it make sense to have a standard button inside the gui called âget lengthâ or something, so after running a process which changes the length of a sample you can press this to update the parameters that need it? (maybe with a toggle, so that it is done automatically each time after processing).
Think I read somewhere that multiplication is more CPU efficient than divide but donât quote me on that, I donât think it will make a difference in this case though, you are only doing the calculation once when you launch the tool GUI and given that the length param returns ms you will be doing length*1000 for time in seconds.
So far I can of two ways to do this, the easy way is to set the frequency to correspond the size of the sample which would work well for loop samples as you could divide the length of the sample into beats and make the frequency match those. The other way as you describe would be a bit more complex as you would need to choose a base note to for the frequency calculations, playing notes at different pitches is going to change frequency anyway, so I think this needs some more thought on how best to implement it. I think I will look at this after I have implemented the breakpoint and pvoc analysis type stuff. That is next on my list now as I think we have a solid base to build on, implementing that stuff may change the way some things are done and introducing envelopes may open up other ways to do beat syncing, so lets seeâŚ
User snapshots like in the sox tool will come eventually but again I want to reach a data structure that is final, I need to implement more of the CDP features before I get to that.
As for the def values, that is a bug in the definitions, âdefâ should work for integers or floating point equally, lua doesnât make a distinction⌠In your âtrofâ definition you have used a comma instead of a period which is why it doesnât work, I also noticed this in a number of your other definitions there are values that look like they should be 0.0001 but instead are 0,0001 - lua uses commas to seperate keys in a table so those will definitely not work properly. Actually just noticed that this is happening in practically every definition⌠commaâs instead of decimal places. Itâs not a massive issue as most of the values are just for min and max but where you have used these for âdefâ you will only get integers.
For example in Grainex extend the latest definition looks like:
arg1 = { name = "wsiz", min = 1,81406, max = length / 3, def = 5, tip = "..." },
arg2 = { name = "trof", min = 0,0, max = 1,0, def = 0,5, tip = "..." },
arg3 = { name = "gpcnt", min = 0, max = 1000, def = 3, tip = "..." },
arg4 = { name = "plus", min = 0,000002, max = length / 1000, def = 0, tip = "..." },
arg5 = { name = "stt", min = 0,0, max = length / 1000, def = 0, tip = "..." },
arg6 = { name = "end", min = 0, max = length / 1000, tip = ".." },
It should actually look like:
arg1 = { name = "wsiz", min = 1.81406, max = length / 3, def = 5, tip = "..." },
arg2 = { name = "trof", min = 0, max = 1, def = 0.5, tip = "..." },
arg3 = { name = "gpcnt", min = 0, max = 1000, def = 3, tip = "..." },
arg4 = { name = "plus", min = 0.000002, max = length / 1000, def = 0, tip = "..." },
arg5 = { name = "stt", min = 0.0, max = length / 1000, def = 0, tip = "..." },
arg6 = { name = "end", min = 0, max = length / 1000, tip = ".." },
Itâs a subtle but important difference and this is happening in numerous places, a find function will pick a lot of these up but not all
I think some of them require a text input file as well, I will look at these in more detailâŚ
Iâve added a refresh GUI button to the next update which will help in most cases, ideally this would be automatic but there doesnât seem to be a way to notify if the sample itself changes, I could make it so that the GUI is automatically refreshed every time you run a process but then you would have to manually refresh if you did an undo and I find myself doing that a lot when I am tweaking⌠So for now I will leave it as a manual toggle unless I find a better way.
Anyway keep up the awesome work with the definitions, it is a lot of fun trying out all the effects, really great mashing samples beyond recognition!
The next big thing I am going to focus on for now is implementing the more interesting processes like morph, phase vocoders, spectral shizzle etc⌠Have you used any of these manually with the command line?
EDIT: Just noticed in your definitions you are using âlength / 1000â which is actually going to give you microseconds⌠If you want seconds you need to do âlength*1000â - Unless of course you want microseconds
EDIT2: I was talking crap in Edit 1
cool, first things first, looking forward to the breakpoint stuff. Lot of the basic stuff in the definitions right now accept them. Curious to how they work out for something like âDistort Filter - time contracting a sound below a certain frequencyâ, automating the frequency parameter on a sound rich in frequency content.
Nice!
I see, will update the definitions soon.
Sounds good to me.
Thanks for making this possible! Hope to update & contribute more when the breakpoint stuff is finalized.
I like using the current tool for creating variations of sounds. Especially for the granular / time-stretchy fx; it saves me time setting up a vst with automations and rendering this to sample for further manipulation. The cdp processes automatically stretch out the result in a sample for layering inside the pattern editor.
Very cool , yeah Iâve checked the spectral stuff but not through commandline, through soundshaper pro. (In this program you can load up multiple sounds, analyze it to create a .ana files and use these in a spectral process that need 2 inputs, run the particular process and have the .ana result automatically synthesized back to sound.
I like that you can select multiple cdp processes in a matrix like thing;
and batch process a sound accordingly. These matrix settings can be stored as presets, helpful when youâve found good effect comboâs. Something like an offline-doofer.
actually I think I started off using length * 1000, but this gave me very large numbers inside the tool gui, have to check again as I could have messed up, accidentally used cycles * 1000 . Looking at something like âsfedit - cut and keep a segment of a sound (in seconds)â in the tool gui, on a loaded sound it says 2.167 , which corresponds with the ~2 second sounds length in the sample editor. If I put in length * 1000, the tool gives me 1083582⌠⌠so it seems like / is the way to go, or am I doing something wrong?
[quote=âDjeroek, post:67, topic:41466â]
aight, fixed the definition def bug;
Attachment 4964 not found.
Awesome!
I have bundled these in this update. Also included a GUI refresh button which will update slider ranges, use this when the tool changes a samples length or if you you select a different sample while the GUI is open.
EDIT:
I figured out how to capture the command output and parse it back to Renoise. I have therefore added a diagnostic print of the command output in this version, every time you run a process it will print in the scripting terminal:
The command path
The arguments supplied
The terminal output i.e. what it would have displayed if you ran it from a command line.
This should help a lot with debugging definitions and working out why some processes do not work.
Now i get errors for all processes:
*** std::logic_error: âViewBuilder: invalid value for slider: â0â. value must be [2e-006 - 4.02868].â
*** stack traceback:
*** [C]: in function âsliderâ
*** main.lua:269: in function âbuild_arg_params_rowâ
*** main.lua:323: in function âbuild_args_columnâ
*** main.lua:355: in function main.lua:350
Works fine here. When does this error pop up? When you launch the tool? Select a preset? Or hit process?
Does anyone else get this? I canât replicate on mac
Are you using any user definitions? If so try renaming the user defs file and then run the tool.
Have you also tried with a range of samples?
If neither of those work try this version of the tool attached.
Let me know what works or otherwise.
Cheers
NOTE: Uninstall the tool before installing this version and only do this if you are getting the same error as xrxs
Ok, thanks so not a platform thing, in which case the other version of the tool i posted is not needed. Iâm guessing it might have something to do with whats in his user definitions. If they are your old ones then the new ones bundled with tool might cause some kind of conflicts. Best thing to do in this case is to clear anything thats been bundled from the user definitions.
Oi Jonas, with regards to parameters that support time varying or breakpoints, have you ever seen any âswitchâ type of parameters that support these, or is it always your standard value type arguments (i.e. no checkbox, just a slider) that can use these?
Iâm trying to work out how to represent these in definitions.
As per the docs, do you know where a parameter is stated as âmay vary over timeâ is the input for this always a breakpoint file i.e. a text document with time value pairs or are there other types of inputs for these.
Very, very helpful indeed, am running through a bunch of non-working presets atm and encountering stuff like needing a different input file or parameter ranges that are wrong. The latter being easy to fix, unfortunately the reverb.exeâs crash and do not report back in the terminal what seems to be the problem, maybe these are just buggy. Will contact the CDP devs about them.
Sometimes I get an error which says 'ERROR: Cannot read parameter 1 [C:\Users\PLUGEX~1\AppData\Local\Temp\Renoise-0-2728\Renoise_TmpFile-0-121.wav]: brkpnt_files not permitted.", could this be because the parameters are read as floating point numbers while this process needs integers only (it thinks Iâm supplying a breakpoint file)?
Would it be possible to have the terminal report somehow visible in the tool gui (or if easier to do in the status update, bottom of the renoise gui)? Sometimes there is no output because parameters relate, one slider needs to be set with a smaller value than another, the terminal output will tell you whatâs wrong and this can be helpful understanding and correcting the process!
note; I put some fixed stuff in the user definitions see below. Could you update this with the current supplied definitions.lua, deleting double entries? Also the âechoes echoâ thingy can be removed as there is no echos.exe, might be left over old stuff in the docs from an obsolete version.
I fixed some parameter ranges for the cantor processes, but even though the terminal reports a list, I canât get any affected output sound. Maybe I just donât understand what it is supposed to do? Will check the manual again. Same for Mchzig Zag, I sometimes get a list as output in the terminal (no affected sound), it can also make Renoise crash (have reported)!
Canât say I remember switches that can need them, or maybe I misunderstand(?), there are processes that need .brk point files or text, data files as infile (instead of having a sound as infile). For example âsynth chordâ (file:///C:/cdpr7/docs/html/cgrosynf.htm), this uses a list with midi pitch values to generate sound output.
If you donât already know, there is an entry on .brk point files in the file formats portion of the docs (as for all other type of data files); file:///C:/cdpr7/docs/html/cfocufrm.htm
Some processes return data files, which can be used as input for other processes. I will go through some of the definitions and see if I can give better examples.
Inevitable feature suggestions :
If you can summon a search-field/box for the preset names through lua magic, please consider this. Might be helpful when the lists of definitions expand.
Also, might be cool to have a batch processing option for example running a process on a multi sampled renoise instrument (e.g; drumkit). Have it go through an instrument, returning results sample for sample.
edit, user definition a couple of fixes;
Attachment 4968 not found.
My system is Win7 64
This happens when i select Grainex Extend process in the first place. If i keep randomly selecting processes after this error notice it goes on showing something like this:
*** std::logic_error: âViewBuilder: trying to remove a view which was not added to the calling parent view.â
*** stack traceback:
*** [C]: in function âremove_childâ
*** main.lua:351: in function main.lua:350
Then i can close CDP interface window and launch it again and everything is working
actually, remove the current entry you have and replace with:
dsp["Grainex Extend - Find grains in a sound, and extend the area that surrounds them"] = {
cmds = { exe = "grainex", mode = "extend", tip = "As with the other GRAIN functions, you will need a reasonably grainy sound as an input, otherwise it won't be able to find any grains and you will probably see the message 'Insufficient valid troughs in the file'.GRAINEX extends an area containing grains, the start and end times being set by the user. The grains are found by envelope troughs and zero-crossings.When the above example command line was run with the input file count.wav, when the output sound got to the number 'three', it was repeated several times before continuing on with the rest of the count up to the number ten. The input sound was 8.066 seconds long, and the output was 18.866 seconds long, i.e., considerably more than the 2.5 seconds specified. NOTES; It is possible to set trof too low. Being relative to the peak level, if the signal doesn't drop that far in level, you may get the Error Message: 'Insufficient grains to proceed' or 'INSUFFICIENT PEAKS IN THE FILE AREA SPECIFIED'. The CDP Usage statement also gives the parameter gpcnt (before PLUS): 'number of grains to treat as a unit in the operations'. However, if set, the process reports too many parameters." },
arg1 = { name = "wsiz", min = 1.81406, max = length / 3, tip = "size of window in milliseconds, which determines the size of the grains to find (Range: 1.81406 to file-length á 3ms)" },
arg2 = { name = "trof", min = 0.0, max = 1.0, def = 0.5, tip = "acceptable trough depth, relative to adjacent peaks (Range: > 0 to < 1 - default: 0.5)" },
arg3 = { name = "plus", min = 0.000002, max = 60, tip = "how much duration to add to the source" },
arg4 = { name = "stt", min = 0.0, max = length / 1000, tip = "time of start of grain material within the source (Range: 0.0 to file-length in seconds)" },
arg5 = { name = "end", min = 0, max = length / 1000, tip = "time of end of grain material within the source (Range: 0 to file-length in seconds and > stt)" },
}
There were too many parameters listed in the docs.
Added support for break point time envelopes, currently these need to be in a .txt file (.brk is also supported in case you have some from soundshaper/soundloom). I will now work on creating these from instrument modulation envelopes but thought Iâd put this out there to be tested and so that definitions could be updated.
How to use
Parameters that support breakpoint time envelopes are listed in the CDP docs as âmay vary over timeâ - These parameters can accept static values or a series of time, value pairs supplied in a .txt or .brk file. If a breakpoint envelope is supplied then the parameter is interpolated between the time points when you hit process.
To update definitions that support this you need to add a insert = âbrkâ to the parameters definition - See the filter definitions at the top of definitions.lua for examples. When you have done this and then load GUI and that command, a button will appear next to that slider (see screenshot). Clicking this will prompt you to point to a .txt or .brk file which containes your time, value pairs. I have also attached an example of such a file that I have been using while testing this out.
When a file is loaded the button will turn green to indicate it is active and the slider value will be ignored. To deactivate the envelope just move the slider and the button will turn back to grey.
Other changes
Included the terminal output in the tool so you donât have to switch windows to see error messages.
Also updated definitions based on recent files posted including the corrected Grainex Extend from two posts back
. Will insert the new length parameter and see what happens, or maybe if I suspect it to be seconds, can I put in âlength*1000â or something?
(would multiplying length with 0,001 instead of dividing with 1000 make any difference computationally?)
, please consider some kind of snapshot system for the parameters. Some kind of preset system which stores set values. This as most processes are pretty particular, anal about when they want to work. Right now I try to update the definitions using "def = " for useful settings, but am I right that floating point defâs between 0 and 1, like 0,5 arenât remembered?
, yeah Iâve checked the spectral stuff but not through commandline, through soundshaper pro. (In this program you can load up multiple sounds, analyze it to create a .ana files and use these in a spectral process that need 2 inputs, run the particular process and have the .ana result automatically synthesized back to sound.
length / 1000 is the way to go!
: