Panic using seq nodes as inputs to seq nodes

[vgel]

This causes a panic in the Rust WASM backend:

~n: seq 1
~a: seq ~n _ _ _
out: sin ~a

Various values in ~n: seq X seem to trigger it. I originally had 440 (not realizing seq takes midi notes), then dropped it to 60, then realized it was probably trying to double-convert midi, so dropped it to 1 to see if that would still panic, and it did. So at least 440, 60, and 1 will cause it to panic.

I think this is a weird thing to try to do given how seq actually works (I was playing around trying to figure it out), so I don't know if this panic is that important, but I figured I'd report it in case my judgement was off.

Backtrace:

Uncaught RuntimeError: unreachable
    at rust_panic (0080ceae:0x10a5fa)
    at _ZN3std9panicking20rust_panic_with_hook17h12b2f0179ff84c92E (0080ceae:0xb7cdb)
    at _ZN3std9panicking19begin_panic_handler28_$u7b$$u7b$closure$u7d$$u7d$17h5a69bb4aef967681E (0080ceae:0x10a829)
    at _ZN3std10sys_common9backtrace26__rust_end_short_backtrace17h1cfd7c1c16d2a171E (0080ceae:0x10a806)
    at rust_begin_unwind (0080ceae:0x40138)
    at _ZN4core9panicking9panic_fmt17hf0d93ec1ac504cf9E (0080ceae:0x9749)
    at _ZN4core9panicking18panic_bounds_check17hebe834b116d5d452E (0080ceae:0x9c2c)
    at _ZN81_$LT$alloc..vec..Vec$LT$T$C$A$GT$$u20$as$u20$core..ops..index..Index$LT$I$GT$$GT$5index17h12de798c45eb5c9eE (0080ceae:0x316e9)
    at _ZN99_$LT$glicol_synth..node..sequencer..seq..Sequencer$u20$as$u20$glicol_synth..node..Node$LT$_$GT$$GT$7process17he136ba40ce49817dE (0080ceae:0x35056)
    at _ZN12glicol_synth5graph22Processor$LT$G$C$_$GT$7process17ha9a3cf893de82f10E (0080ceae:0x998d)
$rust_panic @ 0080ceae:0x10a5fa
$_ZN3std9panicking20rust_panic_with_hook17h12b2f0179ff84c92E @ 0080ceae:0xb7cdb
$_ZN3std9panicking19begin_panic_handler28_$u7b$$u7b$closure$u7d$$u7d$17h5a69bb4aef967681E @ 0080ceae:0x10a829
$_ZN3std10sys_common9backtrace26__rust_end_short_backtrace17h1cfd7c1c16d2a171E @ 0080ceae:0x10a806
$rust_begin_unwind @ 0080ceae:0x40138
$_ZN4core9panicking9panic_fmt17hf0d93ec1ac504cf9E @ 0080ceae:0x9749
$_ZN4core9panicking18panic_bounds_check17hebe834b116d5d452E @ 0080ceae:0x9c2c
$_ZN81_$LT$alloc..vec..Vec$LT$T$C$A$GT$$u20$as$u20$core..ops..index..Index$LT$I$GT$$GT$5index17h12de798c45eb5c9eE @ 0080ceae:0x316e9
$_ZN99_$LT$glicol_synth..node..sequencer..seq..Sequencer$u20$as$u20$glicol_synth..node..Node$LT$_$GT$$GT$7process17he136ba40ce49817dE @ 0080ceae:0x35056
$_ZN12glicol_synth5graph22Processor$LT$G$C$_$GT$7process17ha9a3cf893de82f10E @ 0080ceae:0x998d
$process @ 0080ceae:0x591a
process @ db6bde67-20c3-4b2c-a12c-46dc63cef112:324

[chaosprint]

Hi, thanks for posting it!

Sometimes we just use the seq directly:

o: seq 60 >> sp \808bd

And sometimes we add a speed control to the seq:

o: speed 4.0 >> seq 60 >> sp \808bd

The speed node is a hacking here as it just output signal with the speed on the beginning of every block:

4.0, 0.0, 0.0, 0.0...

I think if you check the source code here. Inside the seq node, it looks for the first and second samples to detect whether it is a speed control.
As I said, this is not robust as you discovered. In the example you provide, the seq X happens to create the same float number pattern as speed, so the seq thinks there is a speed input, together with a reference input. Then it looks for the index 1 from the inputs Vec, which causes the panic as there is just one input.
I think it can be fixed by adding a unique id that only speed and seq know. But I am also considering a better syntax in the next version to avoid using the speed node hacking.

How do you think? is there a particular reason you want to layering different seq? Is is related to #101? I am now working on a node called arranger.

[vgel]

I'm working on using Glicol to generate music from DNA, and IIRC what I was trying to do here was have the Javascript code that parses the DNA not have the notes defined in it. So I was using single-element seqs to define notes like this:

~c: seq 60
~a: seq 69
~t: seq 62
~g: seq 67

and then in JS generating something like seq ~c ~a ~t ~t ~a ~g ~c etc. I didn't realize how seq actually worked so I thought that would work. I think I could have used ~c: choose 60 instead, or maybe just a bare value? I ended up just doing the notes inside the Javascript block (generating seq 60 69 62 62 69 67 60 directly) since it was easier that way.

Regardless, this just came from me misunderstanding how Glicol works so I don't think it's super important to get it to work, especially if things are going to be redone anyways. Not sure what arranger is but it sounds neat :-)

[chaosprint]

I'm working on using Glicol to generate music from DNA, and IIRC what I was trying to do here was have the Javascript code that parses the DNA not have the notes defined in it. So I was using single-element seqs to define notes like this:

~c: seq 60
~a: seq 69
~t: seq 62
~g: seq 67

and then in JS generating something like seq ~c ~a ~t ~t ~a ~g ~c etc. I didn't realize how seq actually worked so I thought that would work. I think I could have used ~c: choose 60 instead, or maybe just a bare value? I ended up just doing the notes inside the Javascript block (generating seq 60 69 62 62 69 67 60 directly) since it was easier that way.

Regardless, this just came from me misunderstanding how Glicol works so I don't think it's super important to get it to work, especially if things are going to be redone anyways. Not sure what arranger is but it sounds neat :-)

@vgel I think choose 60 will work. also sig 60 will also work with better efficiency, but I need to fix the syntax highlight. :)