Currently I'm working on a sequencer and ADSR. They require a lot of 
array manipulation. The system I use, give everything a name, works quite 
well. The names get long and I'd like to shorten tem. Hence te question, 
what are the chance on collisions with names from other file for only 
#local names. I'd like to drop the _sq bit but then I'm left with rather 
general names like _out.


Code snippet:
---%<------%<------%<---

// Setting up the data structure for the sequencer
// Enum primary index
#declare _sq_ctrl = 0;
#declare _sq_out = 1;
#declare _sq_row = 2;
#declare _sq_primary_arr = array[3]{
  "_sq_ctrl",
  "_sq_out", 
  "_sq_row"
} 
// Enum secondary indices
// ctrl
#declare _sq_bpm = 0;
#declare _sq_steps = 1;
#declare _sq_srate = 2;
#declare _sq_beat_samples = 3;
#declare _sq_pattern_samples = 4;
#declare _sq_tick = 5;
#declare _sq_ctrl_arr = array[6]{
  "_sq_bpm",
  "_sq_steps",
  "_sq_srate",
  "_sq_beat_samples",
  "_sq_pattern_samles",
  "_sq_tick"
}
// output  
#declare _sq_clk_gate = 0;
#declare _sq_clk_pulse = 1;
#declare _sq_beat_prog = 2;
#declare _sq_pattern_prog = 3;
#declare _sq_col_curr = 4;
#declare _sq_col_gate = 5;
#declare _sq_row_output = 6;
#declare _sq_output_arr = array[7]{
  "_sq_clk_gate", 
  "_sq_clk_pulse",
  "_sq_beat_prog",
  "_sq_pattern_prog",
  "_sq_col_curr",
  "_sq_col_gate",   
  "_sq_row_output", 
}


#macro SEQinit(BPM, Rows, Steps, SampleRate)
  /*: Initialise a sequencer. Rows, steps are filled with zero's
  They have to be set later with SEQSetRow
  */
  #local SEQarr = array[3];
  
  #local SEQarr[_sq_ctrl] = array[6];
  #local SEQarr[_sq_ctrl][_sq_bpm] = BPM;
  #local SEQarr[_sq_ctrl][_sq_steps] = Steps;
  #local SEQarr[_sq_ctrl][_sq_srate] = SampleRate;
  #local SEQarr[_sq_ctrl][_sq_beat_samples] = BPM2Samples(
    SEQarr[_sq_ctrl][_sq_bpm], SEQarr[_sq_ctrl][_sq_srate]
  );
  #local SEQarr[_sq_ctrl][_sq_pattern_samples] = (
    SEQarr[_sq_ctrl][_sq_beat_samples] * SEQarr[_sq_ctrl][_sq_steps]
  );
  #local SEQarr[_sq_ctrl][_sq_tick] = 0;
  
  #local SEQarr[_sq_out] = array mixed[7];
  #local SEQarr[_sq_out][_sq_clk_gate] = 0;
  #local SEQarr[_sq_out][_sq_clk_pulse] = 0; 
  #local SEQarr[_sq_out][_sq_beat_prog] = 0;
  #local SEQarr[_sq_out][_sq_pattern_prog] =0;
  #local SEQarr[_sq_out][_sq_col_curr] = 0;
  #local SEQarr[_sq_out][_sq_col_gate] = arrFill(Steps, 0);
  #local SEQarr[_sq_out][_sq_row_output] = arrFill(Rows, 0);
  
  #local SEQarr[_sq_row] = array[Rows];
  #for(i, 0, Rows - 1)
    #local SEQarr[_sq_row][i] = arrFill(Steps,0);
  #end
  SEQarr
#end

#macro SEQsetBPM(SEQarr, BPM)
  /*The boom tschack speed*/
  #local SEQarr[_sq_ctrl][_sq_bpm] = BPM;
  #local SEQarr[_sq_ctrl][_sq_beat_samples] = BPM2Samples(SEQarr
[_sq_ctrl][_sq_bpm], SEQarr[_sq_ctrl][_sq_srate]);
  #local SEQarr[_sq_ctrl][_sq_pattern_samples] = SEQarr[_sq_ctrl]
[_sq_beat_samples] * SEQarr[_sq_ctrl][_sq_steps];
#end


#macro SEQsetRow(SEQarr, ValArr, Row)
  /*Set values for a whole row*/
  #local SEQarr[_sq_row][Row] = ValArr;
#end
---%<------%<------%<---

Post a reply to this message

hi,

ingo <ing### [at] tagpovrayorg> wrote:
> ... I'd like to drop the _sq bit but then I'm left with rather
> general names like _out.
> ...
>   "_sq_out",

if you're prepared to only save two chars per, you could still keep your
prefix[*], eg 'sqOut' perhaps.

[*] and if there's a name clash, with prefix you can still use a tool like 'sed'
(on *nix) to make a quick search and replace.


regards, jr.

Post a reply to this message

in news:web.60846401cab7490879819d986cde94f1@news.povray.org jr wrote:

> 'sed'

With the windows "pov ide" changes can be made fast and all the Unix tools 
run fine when using th eproper packages. It just that it all adds up, even 
if it is just a few characters.
#local ADSRarr[_adsr_decay][_adsr_base] = (ADSRarr[_adsr_sustain]
[_adsr_level] - ADSRarr[_adsr_target_ratio][_adsr_dr]) * (1 - ADSRarr
[_adsr_decay][_adsr_coef]);

#local ADSRarr[_decay][_base] = (ADSRarr[_sustain][_Level] - ADSRarr
[_target_ratio][_dr]) * (1 - ADSRarr[_decay][r_coef]);

In general I have no problems with collisions, but with arrays I'm not 
relley sure as I declare an array, the pass it to a macro where I change 
it using #local 'in place' without 'returning' anything.

Guess I'll give it a go and see waht goes wrong, in time,

Cheers,
Ingo

Post a reply to this message

hi,

ingo <ing### [at] tagpovrayorg> wrote:
> in news:web.60846401cab7490879819d986cde94f1@news.povray.org jr wrote:
> > 'sed'
> ... It just that it all adds up, even
> if it is just a few characters.

have long had a "dream" of a 2-pass scene file optimiser.  (pipe dream :-))
pass one analyse scene and strip comments, find and paste all needed snippets
from includes, in pass two replace all identifiers with generated 'ANNN'.
perfectly unreadable, but used as a last step..  anyway, interesting problem.


regards, jr.

Post a reply to this message

in news:web.608490f6cab7490879819d986cde94f1@news.povray.org jr wrote:

> have long had a "dream" of a 2-pass scene file optimiser.

OK, confession time. Many many moons I wrote a python script to parse POV-
Ray scene files and do loop enrolling and a few other manipulations. The 
result ran fast! Python (1.52) not so. Gain, negative :(
The python code I use to colorise the code in HTML is a spin-off of that.

Now, dreaming. Include files compileable to libraries. If I understand it 
right if POV-Ray SDL were written in NIM macros it could be possible. Or 
in LISP. Then again, I happy with the simple language POV-Ray offers. 
There is not much in the way of writing anything and little complexity 
from the language side. 
Also I'm happy with the journey POV-Ray offers. No need for real time 
instant gratification/satisfaction. No bucktlists. No expectations. No GPU 
madness.

Ingo

Post a reply to this message

hi,

(it is late and all that, but a thought just occurred)

ingo <ing### [at] tagpovrayorg> wrote:
> ...
> #local ADSRarr[_decay][_base] = (ADSRarr[_sustain][_Level] - ADSRarr
> [_target_ratio][_dr]) * (1 - ADSRarr[_decay][r_coef]);

how about "devolving" your array into a dictionary with keys for '_decay',
'_target_ratio', etc, parallel arrays, so to speak.  eg:

#local ADSRD._decay._base = (ADSRD._sustain._Level - ADSRD._target_ratio._dr) *
(1 - ADSRD._decay.r_coef);

not an option?

regards, jr.

Post a reply to this message

ingo <ing### [at] tagpovrayorg> wrote:

> The python code I use to colorise the code in HTML is a spin-off of that.

So, was that you?

http://news.povray.org/povray.general/thread/%3C602067b2%241%40news.povray.org%3E/

Post a reply to this message

ingo <ing### [at] tagpovrayorg> wrote:
> Currently I'm working on a sequencer and ADSR. They require a lot of
> array manipulation. The system I use, give everything a name, works quite
> well. The names get long and I'd like to shorten them. Hence the question,
> what are the chance on collisions with names from other file for only
> #local names. I'd like to drop the _sq bit but then I'm left with rather
> general names like _out.

What if you took everything that you wanted to have in a namespace and put them
into an include file.
Each include file could have a number associated with it.
Then instead of hard-coding the names and value assignments, you could use the
parse_string macro to make identifiers like _out1, _out2, etc.

Make a little macro like:

Declare (Lvalue, value)

so that the code reads mostly like usual and there's not a lot of extra code.

When you include one of these files, the first thing it does is check to see if
a global counter variable is set, and what its value is.  Then it uses the next
greater integer for its Lvalue names.

Then you could mix and match them any way you wanted, and you'd _always_ be
guaranteed to have distinct names.

Post a reply to this message

in news:web.6084991ecab749081f9dae3025979125@news.povray.org Bald Eagle
wrote: 

> ingo <ing### [at] tagpovrayorg> wrote:
> 
> 
> So, was that you?
> 


https://ingoogni.nl/download/povsdl2html.py
but I don't remember rendering an image with it.
At a certain moment the code was also used in the pyvon editor

Ingo

Post a reply to this message

in news:web.6084981fcab7490879819d986cde94f1@news.povray.org jr wrote:

> not an option?

Oh yes, now they seem to be fixed.

Ingo

Post a reply to this message