[3.0.12][2.2.92] BUG hunting in TRACKS edit and native editors for MIDI/DMX/AUTOM

Hi @Spork , @musicullum

as new users increase after the release of V3, one of the first things they will interact with are the tracks (moving events clips, drawing, editing) and native editors expecially for automations, midi and dmx. So, i’m facing many bugs in simple edit operations since few versions back in V2. I’m used to it and found differents workarounds to live with this bugs, but i think that for a new user experience, this will be the first impression and facing bugs in operations needed to setup the show will have a negative impact on first impressions.

So, being a first hour user and enthusiast about the results i’ve obtained, i decided to apply a methodical approach in finding and reporducing common bugs in editors and tracks that in my honest opinion, need to be addressed as soon as possible as elementary and basics operations in the software.

Let me know if you have any priorities so i can focus on things you would like to addess first.

I will add a post to this thread for each reproducible issue i identify. I ask other users to not clutter the thread with observations/opinions, but feel free to add focused reproducible issues with steps to reproduce… just give me few hours so i list all the ones i already found, i’ll tell when i finished mines.

Let’s start!

TRACKS event clip move: wrong snap to grid

  • Snap to grid works bad, and worse depending on zoom level
  1. New project
  2. add a track (any type)
  3. draw an event clip 10 bars starting at 1.1.1
  4. snap to grid - 1 bar
  5. move the clip at 2.1.1 ==> you see in info bar the start is set to 1.1.4
  6. zoom out to show more than 100 bars in timaeline
  7. move randomly the event clip ==> you see sometimes the clip start is even worse, like x.4.3 or x.4.2
  8. if you zoom very in at the clip start you’ll se disaligned
  9. NB: the tools to extend/reduce lenght of clip instead, they work as expected moving exactly by x.1.1 at bar beginning
  10. This is the same at any level of snap not only 1 bar

On to next post. cheers, Ciro.

2 Likes

Next one you won’t believe, but try it:

  • DMX/AUTOM/MIDI(for prgchng only) native editors, error in drawing tool after c.ca 50 bars
  1. new project
  2. add dmx track
  3. drav a clip from 1.1.1 to 100.1.1
  4. go to dmx editor, snap to grid 1/4, draw tools
  5. ch1 , draw a pattern on (255) on 1.1.1 off (0) on 1.2.1. Draw it by click& grag up between 1.1.1 and 1.2.1 to reach 255, then click&drag down between 1.2.1 and 1.3.1 to reach 0.

  1. do this at each bar beginning (2.1.1, 3.1.1 and so on) ---- yes it take time but i don’t know if this depend on nuber of points inserted so for reproduction sake do it EDIT: i tested, it works also by just doing it first bars then at bar 52 and at bar 53 it will show the bug

  2. You will reach bar 52 no prob, then at bar 53 this happens .. NB: bar at witch this happens is not always the same.

NOTE: click and drag does not work for MIDI CC, should be useful also on CC
On to next post!

1 Like

I’m trying to reproduce a couple of bugs but are elusive:

  • copy paste DMX/Autom in lane editor: after a certain bar (100 more or less) the paste is done at the wrong location, not at the transport location (snap grid on), expecially if signature/tempo change in the song, things are pasted moved ahead/after by some time.
  • copy paste of multiple DMX channels: if i select points form let’s say chanels 5-10, regardless of with channel is shown in lane, the paste should take lower channel 5 as the base for paste reference. then if i select chanel 20 and paste i expect 5-10 original channels to be pasted to 20-25 . it seems it pastes channels in wrong/random way
  • when drawing DMX autom with LINE tools and snap off, the snap grid value is taken to quantize start and end of line, and that’s very good. then the “reduce events” routine kicks in and expecially for fast lines (1/8th descending from 255 to 0 for example) the start and end point often are removed , this causes incomplete sweepsexpecting blue from 255 to zero, it results in 190something not showing full color power. Then sometimes the reduce event routine move also the timing of points.
  • Tracks: moving different dmx clips one after another , if the second clip has been reduced with left resize tool, hiding the beginning of data, sometimes this interfere and dmx data are sent even if hidden, and block the previus clip from reproduction

For now i have to stop but i’ll come back when i have reproducible steps for theese bugs.

Cheers, Ciro.

1 Like

Up to highlight again all these problems

2 Likes

… fixed. The fix will be included with the next Pre-Releases (2.2.95/3.0.15)

/Michael.

1 Like

… that’s fixed, too. Also ready with the next Pre-Releases (2.2.95/3.0.15)

See you,
Michael.

2 Likes