[fixed 3.2.2] Console hangs/crashes when dumping some VST presetdata

Renoise Tool Development
14

You’re right, it’s the brand that the emoji has selected, they are probably very much into decaf green tea Ledge…I suppose we could make a coffee :coffee: :slight_smile:

15

Yeah, coffee or a good strong builders tea, does the job :coffee:. Must have been a hipster who decided on the green stuff! :slight_smile:

Just reading your edits now. Seems to be getting more complicated…

16

I know! You’re like me, I don’t like bugs in programs either. I avoid the bugs by not programming :slight_smile:

Well at least in the emoji section (whilst taktik is deeply contemplating dumping a 32KB string to the terminal without it crashing) we have a regular cafeteria going on, a doughnut with that coffee Ledge? :doughnut: :yum:

17

We can swat some virtual bugs in here aswell in solidarity with the taktik :ping_pong::bug: :ant::spider:

though I think the virtual cafe inspector won’t like em :policeman:

18

Just mention something here about that ‘pause’. I’m sure you know yourself Ledger/joule/dblue/Raul, that when a computer pauses for say 1,2,3 seconds (or more) when given a seemingly (on the surface) relatively simple task…I get real nervous. Just thought I’d mention that :slight_smile:

Also probably a little bit better way of limiting output from the string ‘active_preset_data’ is to find roughly where the CDATA is in the string and only print up to that point:

local apd_str = renoise.song().selected_instrument.plugin_properties.plugin_device.active_preset_data
local cdata1,cdata2 = string.find(apd_str,"<ParameterChunk><!%[CDATA%[(.+)%]")
if cdata1 ~= nil then
  print(string.sub(apd_str,1,cdata1-1))
  print("--- CDATA HERE ---")
else
  print(apd_str)
end
19

Thanks for snippet @4tey_guest ,

Just looking back on this thread after time to digest: Summary:

  1. active_preset_data printout is useful when using renoise devices, as presets are fully stored as characters. i.e. you can store a preset for the renoise Send-Device locally in a Lua file, to load the Send in a custom preset. I do this in my Send tools for example.

  2. As @dblue points out, plugins can contain all manner of non-charcter data, so to save this data to reload later you would need to save directly to a binary document?

If so, I will limit my Show Device Properties tool to only show active_preset_data for renoise devices and start brushing up on binary file storage in Lua. (Any tips / links welcome!)

20

The CDATA is base64 encoded data from the plugin. It’s encoded in base64 so that there is no corruption of the binary representation (when the string gets decoded from base64 that is) from the ascii xml text string/file Ledge :slight_smile:

21

So it`s safe to store and recall from a text file then, and copy pasting from a print-out keeps integrity?

22

Well you can save the base64 encoded CDATA string to a file sure. If you want to actually see the binary data from the plugin you would run it through a base64 decoder. I assume you are ultimately getting at some sort of fxp preset save/loader?

1 Like
23

I would be interested in some info here: Can you generate a proper .fxp data from the active_preset_data?

24

Hmm, kinda might be possible ffx? Depends what’s in the header of a fxp file? :slight_smile:

25

I don’t know. There are 4 identifier bytes and then plugin individual stuff I think. Maybe the header is included in active_preset_data?

26

Well you can save the base64 encoded CDATA string to a file sure. If you want to actually see the binary data from the plugin you would run it through a base64 decoder. I assume you are ultimately getting at some sort of fxp preset save/loader? Blockquote

Not necessaritly fxp, just for a tool like:

  • Right-click ~save current preset as default
  • Tool watches for newly loaded devices
  • Tool loads saved default

Will be interested on answers to @ffx questions aswell.

27

Quickly looking, nope ffx I’m pretty certain that the fxp header isn’t stored in the CDATA of that string, but you might still be able to bolt on a quick hacky header to that data?

Hold on a second I feel like this is déjà vu ffx? (And when I had an identity on this forum! A normal member. Unlike now :cry: ) → Working with plugin presets (.fxp/.fxb)

1 Like
28

Yay, I hope Taktik will extend “load/save fxp/aupreset” to lua then :stuck_out_tongue:

29

Why did you change your old one in anon35304171 btw?

30

Just one of those things that happens sometimes ffx :slight_smile:

Ah, just to mention also that if you do need to decode the CDATA (for whatever reason) I’ve used this function:

function decbase64(data)
  local b='ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/'
  data = string.gsub(data, '[^'..b..'=]', '')
  return (data:gsub('.', function(x)
      if (x == '=') then return '' end
      local r,f='',(b:find(x)-1)
      for i=6,1,-1 do r=r..(f%2^i-f%2^(i-1)>0 and '1' or '0') end
      return r;
  end):gsub('%d%d%d?%d?%d?%d?%d?%d?', function(x)
      if (#x ~= 8) then return '' end
      local c=0
      for i=1,8 do c=c+(x:sub(i,i)=='1' and 2^(8-i) or 0) end
      return string.char(c)
  end))
end

I haven’t written it or anything, so how robust it is etc.

31

Thanks 4Tey, yet I will wait for Taktik then. I was planning to make a custom fxp/aupreset preset manager tool, if this won’t be optimized.

1 Like
32

The problem here is not that it’s dumping non ASCI characters. The preset data is XML, so it’s plain ASCII already.

But the plugin’s CDATA in the dump can be really huge (several megabytes) and, which really is the problem here, consists of a single line only, which the terminal can’t handle efficiently right now. I’ll check if I can optimize this a bit.

Either way, it’s a plain scripting terminal display issue. The preset data is exported just fine.

There are no plans to add fxp or aupreset im/exports.

33

Ok, good to know,

thanks for looking into this taktik!