Tool Idea: Modular Sample Processing Framework

Renoise Tools
1

I’m thinking of a tool that would serve as a general framework for sample processing. Something that could load in separate processing modules written in Lua. It would handle all the basic stuff like GUI and general processing (writing sample data, managing sample and instrument list) et cetera.
The actual modules could be more lightweight, sort of “original sample data in, processed sample data out” -things.
I think this would lower the threshold of creating simple (and complicated) sample editing scripts. Also it could make sample editing with tools a more streamlined experience for users by providing a consistent GUI. -> Better user experience.

Anyone dig this? I’d go for this myself but I’m rather preoccupied.

2

Sounds like a great idea.
Specially working with the mapping areas can be a tedious job.
Simplifying processes with wrappers sounds like a nice idea. It is not a thing that can be done by one person anyway.

What i would suggest is if one has written code in this area (and i know some have done things with the sample editor and mappings, including myself), considering what could be useful and then try to pull that piece of code out and create a class from it.
No doubt we would have several snippets in no time to assemble a library (need to agree on the structure somehow to make it managable by multiple persons).

3

Interesting idea. What sample processing are you thinking?

I have a lot of code that works with sample data and mappings with I could contribute.

Also, what sort of interface are you thinking?

I usually work with sample data as a lua table of sample frame points. It’s fairly easy to create functions which read/write tables like this to samples in Renoise, e.g:

  
read_sample_data(sample_reference) -> returns table of data points  
write_sample_data(sample_reference, table) -> writes table of data points to sample
4

Nice idea!

I think it would be nice to be able to layer sample processing modules, i.e.:

  
 data.pipe(removeSilence).pipe(maximizeVolume).pipe(...)

if possible.

Edit:

Btw about mappings, are there any conventions (should there be?)
for how to map keyboard shortcuts in tools?

5

I’m no coder or anything, but I remember retired forum member Johann wanting a better way of handling/manipulating sample data through Lua, other then collecting data in tables as it was slow. A way to directly access sample data in memory? His ‘run cmd on selection’ tool ( New Tool: Run Cmd On Selection ) suffered because of the then Api, dunno if anything has changed in that regard?

6

Indeed such functions, but i can also think of these:

   
set_sample_selection(ins,sample,start,end)   
copy_selection(src_ins,src_sample,tgt_ins,_tgt_sample,tgt_position)

But also very necessary gadgets like embedding the idle-notifier, to prevent renoise from firing a script is hanging error and basic progress stuff like:

  
function progress_meter(title, pmin, pmax, pvalue)  
 if dialog == nil then  
 progress_slider = vb:row {  
 vb:text {  
 id="meter_text",  
 width = 20,  
 text = (pvalue*100).."%"  
 },  
 vb:minislider {  
 id="meter",  
 min = pmin,  
 max = pmax,  
 value = pvalue,  
 active = false,  
 notifier = function(value)  
 vb.views.meter_text.text = (value*100).."%"  
 end  
 }  
 }  
 dialog_content = vb:column {  
 margin = DIALOG_MARGIN,  
 spacing = CONTENT_SPACING,  
 vb:row{  
 spacing = 4*CONTENT_SPACING,  
  
 vb:column {  
 spacing = CONTENT_SPACING,  
  
 progress_slider,   
 },  
 },  
 }  
 else  
 if vb.views.meter.value > 0 then  
 vb.views.meter.value = 0  
 end  
 end  
 if not dialog or not dialog.visible then  
 dialog = renoise.app():show_custom_dialog(title, dialog_content)  
 end   
end
7

The mappings was about the sample-layer mappings. Not keyboard shortcuts.

I don’t think this situation can be really improved, because an external application is used to process the content.
You can use the idle notifier to update Renoise during copying and pasting of the frame-buffer data (he perhaps didn’t used that trick), but once the data has been stored on disc and submitted to an external program, it means waiting out the ride until the external program is ready.

8

The processing in the external program(s) often happens really quickly (depending on what dsp process you’re using, length of the sample), but then the processed result has to be collected in a table, then pasted in a new instrument slot (if I remember correctly)… and this takes ages… having to click away a lot of ‘script is taking to long, do you want to abort yes/no?’ notices. Shame Johann has left these parts, probably could explain the bottleneck a lot better!

9

nevermind

10

I understand, i have walked the same road when writing the slices to instrument tool. When using the idle notifier to give Renoise some room, this problem got resolved. When adding the progress meter, i also got an insight of frankly how long stuff takes. Thanks to some piece of Taktiks code, i could improve the speed of the process tremendously.
You can choose to work either frame by frame or simply copy a complete range. The first choice is a very poor choice.

11

The only slow part is really getting the data in/out of renoise into a Lua table.

If you work on a single copy of the table then actual operations are fast (in my experience).