New Tool (2.7, 2.8): Step Sequencer

Got an error when installing 1.81 on Renoise 2.8.0 b4 saying the tool failed to load::

main.lua: bad header in precompiled chunk  

It still says it was successfully installed but doesn’t appear to be. The same error message pops on restarting renoise. Same thing happens after uninstalling/reinstalling.

Hi Cie, when I first ran the stepsequencer, I got the regular interface. Then I closed the GUI. Created a new song, and loaded a sample, and started the script, and got:

*** std::logic_error: 'ViewBuilder: invalid index for popup: '3'. value must be [1 - 1].'  
*** stack traceback:  
*** [C]: in function 'popup'  
*** gui.lua:1308: in function 'create_tracks_for_gui'  
*** gui.lua:1822: in function 'create_gui_contents'  
*** main.lua:67: in function <49><br>```

<br>
<br>
and the resultant gui looked like this:<br>
<img src="http://scene.org/~esa/renoise/stepseq_bug1.png"></49>

Ok, so I looked up “bad header” error and it means trying to run a script compiled in a different platform/architecture, for instance, 32-bit x 64-bit, ppc x intel, etc. doesn’t work.

I’m running Renoise 2.8 beta in 64bit on OS X Snow Leopard 10.6.8.

Same error here.

liblua :

liblua5.1-0 - 5.1.4-12
liblua5.2-0 - 5.2.0~rc5-1
liblua50 - 5.0.3-6
liblualib50 - 5.0.3-6

Kernel :

Linux 3.1.0-6.dmz.1-liquorix-amd64 #1 ZEN SMP PREEMPT Sat Dec 24 04:08:45 CST 2011 x86_64 GNU/Linux

(looks like the same error you fixed in the previous release)

edit: that’s on Renoise 2.8b5

Thilo, it looks so great in your video!!!

Unfortunately I can’t install it
I’m on Windows 7 64 bit

I can install the sequencer in Renoise 2.8.0 b5 32bit, but get the following error when starting the sequencer:

gui.lua:1033: unknown property or function ‘plugin_name’ for an object of type ‘InstrumentPluginProperties’
stack traceback:
[C]: in function ‘_error’
[string “do…”]:47: in function <[string “do…”]:35>
gui.lua:1033: in function ‘build_instrument_names_table’
gui.lua:1336: in function ‘create_gui’
main.lua:63: in function main.lua:46

When I install it in Renoise 2.8.0 b5 64bit, I get the following message @ startup

‘C:\Users\dan\AppData\Roaming\Renoise\V2.8.0\Scripts\Tools\net.stepsequencer.StepSequencer.xrnx’ failed to load.
Please remove this tool or contact the author (Cie [cie@cie-online.de]) for assistance…
main.lua: bad header in precompiled chunk

Installing in Renoise 2.7.2 works , but note features won’t work, like you wrote…
damn, I need to test this :)

Hope it helps
Daniel

Thanks for testing and your reports! :)
Seems to be some more work then…

The first error should be fixed.
Hm, I did not have any performance issues when loading the demo song. What kind of pc do you have?
Do you have more info about the undo collection? I have not heard of it.

Yes, this message appears if you are using a 32 bit compiled tool on 64 bit Renoise or vice versa. I had not compiled for 64 bit, sorry. I have added a version for 64 bit users now.

[quote=“Jonas, post:123, topic:29567”]
Hi Cie, when I first ran the stepsequencer, I got the regular interface. Then I closed the GUI. Created a new song, and loaded a sample, and started the script, and got:

*** std::logic_error: 'ViewBuilder: invalid index for popup: '3'. value must be [1 - 1].'  
*** stack traceback:  
*** [C]: in function 'popup'  
*** gui.lua:1308: in function 'create_tracks_for_gui'  
*** gui.lua:1822: in function 'create_gui_contents'  
*** main.lua:67: in function <49><br>```

<br>
<br>
and the resultant gui looked like this:<br>
<img src="http://scene.org/~esa/renoise/stepseq_bug1.png"><br>[/quote]<br>
Should be fixed.<br>
The problem here was, that in 2.8 empty instrument slot names are not an empty string '' anymore, but nil.<br>
<br>
Please check out new beta 1.82 on first page. There may be some errors still...<br>
Edit: I am using 2.8 B5</49>

I wasn’t speaking about the particular demo song, couldn’t get the tool to start in that one due to the error!

In some songs with vst’s that have a lot of parameters, Renoise gui/pattern editor scrolling gets all sluggish, doesn’t update quick enough, while trying to initialize the parameter matrix in your tool.

Also with certain songs, at every pattern change while playing, it feels like there is a visual delay/cpu hick up. Like the tool, pre-loads / fetches all pattern content from the editor in memory or something. Maybe the only way to really optimize it, is to get a native step-sequencer tab? :drummer:

Right now, if you have midi-mapped a parameter in the tool’s matrix to a knob, every step in between first change and final position is remembered. It was just an idea for optimizing / remember less steps if possible?

The installation of the new beta version (1.82) worked well in 2.8.0 b5 32 bit for me!
(still get the bad header in precompiled chunk error in 64 bit version)

I love the new Control Matrix features!
The delay function is so usefull for programming shuffled beats
and it is so much more fun to play with my controler knobs
instead of hacking in numbers :walkman:

Could you easily adapt the note length control to the matrix or make it mapable?

Again congrats Thilo!
It’s such a powerful tool for me.
Dan

By the way Native Instruemnts did not manage to make the notelength parameter mapable in the Maschine Step Sequencer.
If you manage to get it working, I’m pretty sure I’ll have some new customers for your launchpad edition @ the NI-forum soon ;)

Back on topic…

Ah I see. The mentioned error should be fixed.
Yes, the hickup appears (in quite complex songs) when the pattern index changes. The tool loads the notes and values of the new pattern into the step sequencer automatically, so the complete pattern must be parsed. This may take some cpu time.
Actually this is not necessary if the step sequencer window is not opened. Unfortunately there seem no possibility in the lua api yet, to check if the tool window is opened or not (I asked that it in another thread).
Maybe as a workaround I could make an option in the preferences whether on pattern change the sequencer should be updated automatically.

Edit: The problem was solved in the mentioned thread. Now changed like following: if the step sequencer window is not opened, and the pattern changes, there will be parsed nothing, which should remove the hickup.

I doubt that it is possible to access that behaviour with the current api. When the user changes a parameter, a notifier is called and writes the new value in memory. When having a complex song, and using pattern effect changes, the updating process is quite slow. No I understand what you mean with the undo-queue. I think this may something to optimize by the devs; as I can not get the “final” change only.

Great! :)
Please use the 64 bit version of the tool for the 64 bit Renoise version.

Thank you very much, very nice to read and very motivating to me :)

Actually the length of a note is determined by the distance of the next following ‘Off’ note. You can set the notelength in the control-matrix for every note like the following: Just select the controller type “Note” and set a note as ‘Off’ x steps behind the step (note) you wish to cut. Do not forget to activate the ‘Off’ step in the step sequencer. So you can achieve a note length of your choice:
2833 note_off.png

Or do you mean another behaviour?

There is also a new version (1.83) available:

  • fixed bug on editstep/pattern/page change: only automation values in the matrix were updated
  • update pattern effects list to new 2.8 commands

Perfect! Didn’t realize the “note off command” is already in there.
I was just irritated by the extra lenght parameter next to the set note fields …

Danke for the update!

No doubt :)
Same thing again with the 64 bit version (not at all important to me):
Sequencer 1.83 64 bit not working in Renoise 2.80 64 b5
Sequencer 1.83 32 bit working fine in Renoise 2.80 32 b5
Plattform is WIN 7 64

Anyone else?

daniel

I have weird stuff happening when opening the newest version in Renoise b5 upon tool initialization…after some waiting when the gui fetches all the stuff from the pattern editor, note events in the pattern editor change! Resulting in a different sounding track.

No error pop ups, just a different sounding track after opening lauflicht…it looks like if you have different sample instruments in one track, the first sample instrument is used for ALL other instrument note events. Don’t have time now to test further, but maybe others can confirm weirdness?

Under certain circumstances that happened in this case; I could reproduce it. It will be fixed in next beta. It will always happen, if you change the instrument of the track in the appropriate select box of the sequencer (that is no bug, but a feature, to quick change instruments ;)
In general you should not use different instruments in one track when using the step sequencer, but one instrument per track. When setting a step always the first instrument in the track will be taken. A sample bank is no problem.

@dtunez: seems that the 64 bit version does not run on Win64, but the 32 bit version; but for Linux/Mac 64 the 64 bit version works.
Anyway there is no difference at all between 32 and 64, just a different compiling.

Fixed.

New beta version (1.84) available on the first page.

wow!!

Still getting the same bad header error with 1.84 64bit version on Renoise 2.8b5 64 bit on OSX Snow Leopard.

Had a bug trying to access the preferences of the tool while running a song:

Think I broke it :) , changing the preferences anyway to 32 and re-opening lauflicht creates a broken gui/missing elements and the following notice:

on windows vista, 32 bit btw.

Thanks, Jonas. Should be fixed in new beta 1.86 (link to first post)
also fixed bugs in Velocity/Panning in the controller matrix.

Thanks for the fix.

I can make Renoise crash by using your newest update and a particular song where I loop 2 patterns, but unfortunately no hints in the log / or script error notice.

As said before, with certain patterns containing a lot of data, during pattern switching from one to the other, there is a delay / visual hick up. In this song, continually looping 2 heavy patterns Renoise crashes. Maybe you/someone can replicate the crash initializing Lauflicht on heavy tracks?