Support

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?

Post any examples or modules that you want to share here

CPU efficient pianoroll-less RAM?

Postby nix » Sat May 02, 2015 11:44 pm

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->
DS_RC2015.fsm
(371.92 KiB) Downloaded 1268 times


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:
Image
User avatar
nix
 
Posts: 817
Joined: Tue Jul 13, 2010 10:51 am

Re: CPU efficient pianoroll-less RAM?

Postby Nubeat7 » Sun May 03, 2015 1:04 pm

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
Attachments
seq1.png
seq1.png (20.63 KiB) Viewed 27030 times
User avatar
Nubeat7
 
Posts: 1347
Joined: Sat Apr 14, 2012 9:59 am
Location: Vienna

Re: CPU efficient pianoroll-less RAM?

Postby tulamide » Sun May 03, 2015 4:43 pm

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?

Postby nix » Sun May 03, 2015 9:26 pm

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
User avatar
nix
 
Posts: 817
Joined: Tue Jul 13, 2010 10:51 am

Re: CPU efficient pianoroll-less RAM?

Postby tulamide » Sun May 03, 2015 11:14 pm

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?

Postby nix » Mon May 04, 2015 2:02 am

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.
User avatar
nix
 
Posts: 817
Joined: Tue Jul 13, 2010 10:51 am

Re: CPU efficient pianoroll-less RAM?

Postby Youlean » Mon May 04, 2015 11:36 am

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?

Postby nix » Mon May 04, 2015 3:34 pm

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
User avatar
nix
 
Posts: 817
Joined: Tue Jul 13, 2010 10:51 am

Re: CPU efficient pianoroll-less RAM?

Postby Youlean » Tue May 05, 2015 9:37 pm

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?

Postby Nubeat7 » Wed May 06, 2015 8:45 am

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...
Attachments
seqDCnubeat7.fsm
(9.6 KiB) Downloaded 1237 times
Last edited by Nubeat7 on Wed May 06, 2015 12:12 pm, edited 1 time in total.
User avatar
Nubeat7
 
Posts: 1347
Joined: Sat Apr 14, 2012 9:59 am
Location: Vienna

Next

Return to User Examples

Who is online

Users browsing this forum: No registered users and 27 guests