If you have a problem or need to report a bug please email : support@dsprobotics.com
There are 3 sections to this support area:
DOWNLOADS: access to product manuals, support files and drivers
HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects
USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here
NEW REGISTRATIONS - please contact us if you wish to register on the forum
Users are reminded of the forum rules they sign up to which prohibits any activity that violates any laws including posting material covered by copyright
CPU efficient pianoroll-less RAM?
17 posts
• Page 1 of 2 • 1, 2
CPU efficient pianoroll-less RAM?
Heya peeps 8D
I am investigating my open source VST host's feasibility-
and one point where I am hung-up is the amount of RAM the
current sequencer requires.
Here is the piano roll/sequencer->
The 2 elements which require RAM are the 4096 X 128 X 32 preset parameter arrays,
and the Ruby reader.
These 2 elements require the same amount of RAM each, something like 85 meg each,
which adds up too fast when(theoretically) writing a song.
Has anyone got any hints on chopping the RAM usage out?
This is an open source project,
and I am seeking contributors,
besides this particular matter.
Cheers- hope the binaries are doing cool things hehe
edit(20 mins later)-
oh, everyone downloaded it from the first views.
If you are interested in the host itself,
here is the thread at KVR->
http://www.kvraudio.com/forum/viewtopic ... 7&t=399323
screen:

I am investigating my open source VST host's feasibility-
and one point where I am hung-up is the amount of RAM the
current sequencer requires.
Here is the piano roll/sequencer->
The 2 elements which require RAM are the 4096 X 128 X 32 preset parameter arrays,
and the Ruby reader.
These 2 elements require the same amount of RAM each, something like 85 meg each,
which adds up too fast when(theoretically) writing a song.
Has anyone got any hints on chopping the RAM usage out?
This is an open source project,
and I am seeking contributors,
besides this particular matter.
Cheers- hope the binaries are doing cool things hehe
edit(20 mins later)-
oh, everyone downloaded it from the first views.
If you are interested in the host itself,
here is the thread at KVR->
http://www.kvraudio.com/forum/viewtopic ... 7&t=399323
screen:

-
nix - Posts: 817
- Joined: Tue Jul 13, 2010 10:51 am
Re: CPU efficient pianoroll-less RAM?
i did a sequenzer for kortezzz in ruby and during the development i ran into the same issue, so i changed the concept,
instead of saving every possible note event on each notenr, which is a lot, i save only each note which is drawn and limit the possible number of notes you can draw to a useful value (in my case i think it was 600 notes in 6 sequence sections or so) - dynamic sized arrays would be so great here
...
the trick is to save a note event in 4 arrays, one array for the lenght, one for notenr, one for the position in time and one for volume, like this you can reduce the preset arrays to 4 arrays with the max number of notes you want to allow
in your case you have a global notelenght so it would be one array less..
but this would need a big rewriting of the presetsystem and there should be something when the maximum of used notes is reached
here is a picture of the sequencer
instead of saving every possible note event on each notenr, which is a lot, i save only each note which is drawn and limit the possible number of notes you can draw to a useful value (in my case i think it was 600 notes in 6 sequence sections or so) - dynamic sized arrays would be so great here

the trick is to save a note event in 4 arrays, one array for the lenght, one for notenr, one for the position in time and one for volume, like this you can reduce the preset arrays to 4 arrays with the max number of notes you want to allow
in your case you have a global notelenght so it would be one array less..
but this would need a big rewriting of the presetsystem and there should be something when the maximum of used notes is reached
here is a picture of the sequencer
- Attachments
-
- seq1.png (20.63 KiB) Viewed 27033 times
-
Nubeat7 - Posts: 1347
- Joined: Sat Apr 14, 2012 9:59 am
- Location: Vienna
Re: CPU efficient pianoroll-less RAM?
Nubeat7 wrote:the trick is to save a note event in 4 arrays, one array for the lenght, one for notenr, one for the position in time and one for volume, like this you can reduce the preset arrays to 4 arrays with the max number of notes you want to allow
This could be further reduced, if the sequencer is limited in step-sizes up to 256. You'd then be able to use 8-bit integers per note event channel, e.g. notenumber 64, length 2 steps, time 8th step, velocity 127
Those can be expressed in hex as 40, 2, 8, 7F. Now just bring them together and store them as one float '4002087f'
-> reduced to one array
"There lies the dog buried" (German saying translated literally)
- tulamide
- Posts: 2714
- Joined: Sat Jun 21, 2014 2:48 pm
- Location: Germany
Re: CPU efficient pianoroll-less RAM?
Thanks fellas,
I'll think on it.
How about the ruby code that reads the arrays?
Why does that require RAM?
I could halve it if that could be mitigated.
And yeah- you're looking at the hand of Nubeat there,
he helped a whole lot to condense that code
I'll think on it.
How about the ruby code that reads the arrays?
Why does that require RAM?
I could halve it if that could be mitigated.
And yeah- you're looking at the hand of Nubeat there,
he helped a whole lot to condense that code
-
nix - Posts: 817
- Joined: Tue Jul 13, 2010 10:51 am
Re: CPU efficient pianoroll-less RAM?
nix wrote:Thanks fellas,
I'll think on it.
How about the ruby code that reads the arrays?
Why does that require RAM?
I could halve it if that could be mitigated.
And yeah- you're looking at the hand of Nubeat there,
he helped a whole lot to condense that code
Do you mean the ruby module called "seq to midi"? If so, there are 128 inputs, each an array with 128 values. That's 65kB. flatten is called non-destructive (each array is copied to a flattened version of itself). That's 130kB. I did not check all the other arrays in there, probably another 65-130kB. That's from just looking at the Ruby code. The garbage collection of Ruby is relatively slow, so it might add up 1 or 2 MB before releasing, but I can't really tell where the 85 MB are coming from. (Maybe I misunderstood the input arrays, so that they hold more data?)
"There lies the dog buried" (German saying translated literally)
- tulamide
- Posts: 2714
- Joined: Sat Jun 21, 2014 2:48 pm
- Location: Germany
Re: CPU efficient pianoroll-less RAM?
OK- that answers my question tulamide, -thanks!
the array inputs are arrays.
Each one is 4096 values long,
because the entire song/sequence is stored end on end
ie. 32 patterns
I'll keep thinking about this before I try something.
I can't actually read hex, that would be something worth learning.
the array inputs are arrays.
Each one is 4096 values long,
because the entire song/sequence is stored end on end
ie. 32 patterns
I'll keep thinking about this before I try something.
I can't actually read hex, that would be something worth learning.
-
nix - Posts: 817
- Joined: Tue Jul 13, 2010 10:51 am
Re: CPU efficient pianoroll-less RAM?
nix wrote:OK- that answers my question tulamide, -thanks!
the array inputs are arrays.
Each one is 4096 values long,
because the entire song/sequence is stored end on end
ie. 32 patterns
I'll keep thinking about this before I try something.
I can't actually read hex, that would be something worth learning.
Hey nix, in order to help you, you must first explain me what is " slot no", "counter paste" and "counter clear" used for...
- Youlean
- Posts: 176
- Joined: Mon Jun 09, 2014 2:49 pm
Re: CPU efficient pianoroll-less RAM?
Slot No. is pattern number, from 0-31
Counter Paste is a counter that writes a pattern when you copy/paste a pattern
Counter Clear is a counter that clears the current pattern
I'm not sure why I used a counter that passes over the values,
when I could have switched an array though.
These functions do not require much RAM IMO
The 2 elements I mentioned are the heavy ones
Counter Paste is a counter that writes a pattern when you copy/paste a pattern
Counter Clear is a counter that clears the current pattern
I'm not sure why I used a counter that passes over the values,
when I could have switched an array though.
These functions do not require much RAM IMO
The 2 elements I mentioned are the heavy ones
-
nix - Posts: 817
- Joined: Tue Jul 13, 2010 10:51 am
Re: CPU efficient pianoroll-less RAM?
nix wrote:Slot No. is pattern number, from 0-31
Counter Paste is a counter that writes a pattern when you copy/paste a pattern
Counter Clear is a counter that clears the current pattern
I'm not sure why I used a counter that passes over the values,
when I could have switched an array though.
These functions do not require much RAM IMO
The 2 elements I mentioned are the heavy ones
Thanks. I have tried to modify your schematic, but I realized that it will be really time consuming, so I will suggest you what you can do to improve it.
If you don't plan to change GUI that much, render it as bitmaps to save RAM and speed up redrawing. For redrawing use redraw area, don't redraw in Transpose notes module when changing the slot number, store in preset just notes that are being inserted, you can even store in character preset as 128 characters bins.
- Youlean
- Posts: 176
- Joined: Mon Jun 09, 2014 2:49 pm
Re: CPU efficient pianoroll-less RAM?
here is a basic prototype of how you can handle the preset management
the thing is, that if you want to choose this, the whole system would need a huge rewrite
this would also have some advantages to the create midinotes part which also would need to be written new but in a much easier way than it is now (a ticker would run at the max resolution - maybe 64th notes or so - and check if a note starts at the actual position of the ticker)
also the way of the sequence slots (sections) will be a bit tricky (i did draw a long sequence with all sections inside and show only the actual selected section on the screen)
so really a lot of work...
the thing is, that if you want to choose this, the whole system would need a huge rewrite
this would also have some advantages to the create midinotes part which also would need to be written new but in a much easier way than it is now (a ticker would run at the max resolution - maybe 64th notes or so - and check if a note starts at the actual position of the ticker)
also the way of the sequence slots (sections) will be a bit tricky (i did draw a long sequence with all sections inside and show only the actual selected section on the screen)
so really a lot of work...
- Attachments
-
seqDCnubeat7.fsm
- (9.6 KiB) Downloaded 1238 times
Last edited by Nubeat7 on Wed May 06, 2015 12:12 pm, edited 1 time in total.
-
Nubeat7 - Posts: 1347
- Joined: Sat Apr 14, 2012 9:59 am
- Location: Vienna
17 posts
• Page 1 of 2 • 1, 2
Who is online
Users browsing this forum: No registered users and 28 guests