Zynewave.
LiquidProj3ctAwesome Frits. The only minor bug I find is this:
The last stretch of the curve hasn’t slope in sequencer. Curve editor snap is 1/16, while sequencer snap is set to 1/1.
Best regards 🙂
Zynewave@LiquidProj3ct wrote:
The last stretch of the curve hasn’t slope in sequencer. Curve editor snap is 1/16, while sequencer snap is set to 1/1.
It’s not a bug, but perhaps a bit confusing. It’s because the snapped point at bar 2 is actually beyond the end of the curve sequence event. When the end of a sequence/sound event is snapped at bar 2, it will stop playing events/audio just before the bar 2 start.
Maybe I should change this behaviour for track automation curves, and actually include point events snapped on the end of curve sequence events?
druidHm interesting. I think that people probably think of a clip as everything between those points, but *inclusive*, meaning right on the dot of the end perimeter as well.
So I think including points on the 2nd bar should occur, but I can understand why you didn’t do that. The logic is, that event is only as long as just before bar 2, but I think most people think of event lengths as inclusive of their boundaries as well.
I won’t mind either way though, I think.
LiquidProj3ctI think it would be more accurate, no big deal although
Conquistador@Zynewave wrote:
The 2.15 release will feature a revision of the way that automation (parameter tracks) are handled. For years, the old system has often been the subject of discussion on this forum, so this update has been under preparation for a long time.
The old system handled each curve sequence on a parameter track as a separate playback object, similar to how note sequences and sound events are handled. This had the effect that parameters reset to default values when playback went over a timeline section where there were no curve sequence events. Many users have reported this to be an undesirable behaviour.
The new system still uses the same old curve sequence events and curve editor, but instead of handling all curve sequence event as individual curves, there now is a single track curve. The points in this track curve is made up of the points in the visible part of the curve sequences. The track curve stretches from the start of the arrangement to infinity on the timeline. If you have two joining curve sequences then the track curve is seemless from the last point in the first sequence to the first point in the following sequence. In the old system you could get a sharp edge in the transition between the two curve sequences.
The new system also allows for curve sequence events to be overlapped. This resulted in unpredictable playback with the old system, as playback of the individual curves would conflict. Overlapping curve sequence events can now be used to for example create a fade in/out on top of a longer fade curve.
I’ve considered many different approaches, before settling on this design. Full backward compatibility with older projects was not possible. If your older projects relies on the parameter reverting to default values on parameter tracks, you will need to modify these curves by adding points that will set the curve to the default value. I’m sorry for this inconvenience, but I found it necessary in order to get the best possible automation system.
I still need to do a lot of testing and optimization, and I’m still tracking down some crash-bugs. Those that are eager to try the new system can download the 2.15 beta1 in the VIP lounge.
Please post your thoughts about the new automation system.
Thanks for giving this a look in Frits! Seems like a sensible approach. I don’t have much time to test it though sorry.
I would be very interested in aMUSEd comments. I’ll bump the other thread as he may not be checking the forum (for now) but his inbox instead for replies to that thread about automation in the support forum.
aMUSEdSorry I’ve only had a brief opportunity to test this so far. Busy with other things. It seemed to work OK – didn’t need to insert a marker to make it record properly this time and no reversions to zero but I’ll try and test some more if I get a chance this weekend.
Conquistador@aMUSEd wrote:
Sorry I’ve only had a brief opportunity to test this so far. Busy with other things. It seemed to work OK – didn’t need to insert a marker to make it record properly this time and no reversions to zero but I’ll try and test some more if I get a chance this weekend.
Cheers aMUSEd. 8)
I just thought you had not seen it yet and were going to miss an opportunity to have your say as the revision is a direct response to user feedback and it looks like Frits might wrap things up within a week or even a few days from now.
But yes I too have little time for testing 2.15 as well ATM.
Zynewave@Zynewave wrote:
@LiquidProj3ct wrote:
The last stretch of the curve hasn’t slope in sequencer. Curve editor snap is 1/16, while sequencer snap is set to 1/1.
It’s not a bug, but perhaps a bit confusing. It’s because the snapped point at bar 2 is actually beyond the end of the curve sequence event. When the end of a sequence/sound event is snapped at bar 2, it will stop playing events/audio just before the bar 2 start.
Maybe I should change this behaviour for track automation curves, and actually include point events snapped on the end of curve sequence events?
There is a new beta5 where point events snapped on the sequence end is included in the track curve.
Beta5 also has a new “transform to grid aligned points” command in the curve editor. The old “digitize spline curve” is renamed to “transform points to spline curve”. Next I’m going to add a “transform spline curve to lines” command.
I’m not home during the weekend, so I may only be able to respond to your feedback late on monday.
H-manHi all,
Just chiming in to say that once agian I’m diggin’ the updates 😀 I think that most of the bugs or misunderstandings have been worked through already.
One question tho Frits, does the record button on the parameter track(s) do anything?
Is it meant to be linked to the device automation record buttons? :-k
LiquidProj3ct@Zynewave wrote:
There is a new beta5 where point events snapped on the sequence end is included in the track curve.
It works impeccable! ThaNks and good weekend! 😀
Conquistador@Zynewave wrote:
includes general optimization and cleanup of a large part of the engine.
Audio engine overall or just automation? What was the clean up? What sort of difference should one notice?
aMUSEdJust experimenting some more with the automation – how come it records fine if I use the mouse to move a knob or slider but if I use midi learn to assign it to a hardware controller it ignores it?
aMUSEdApart from that (and still getting the divide by zero crashes occasionally at first run of the programme) Podium finally is working for me with regards to recording my playing with plugins faithfully. That is very pleasing and it moves Podium from something I try occasionally to see how it’s progressing to something I can consider using as my main host (although after this some attention to project management would be greatly appreciated). Thanks for this Fritz 🙂
aMUSEd@Zynewave wrote:
@Zynewave wrote:
@LiquidProj3ct wrote:
The last stretch of the curve hasn’t slope in sequencer. Curve editor snap is 1/16, while sequencer snap is set to 1/1.
It’s not a bug, but perhaps a bit confusing. It’s because the snapped point at bar 2 is actually beyond the end of the curve sequence event. When the end of a sequence/sound event is snapped at bar 2, it will stop playing events/audio just before the bar 2 start.
Maybe I should change this behaviour for track automation curves, and actually include point events snapped on the end of curve sequence events?
There is a new beta5 where point events snapped on the sequence end is included in the track curve.
Beta5 also has a new “transform to grid aligned points” command in the curve editor. The old “digitize spline curve” is renamed to “transform points to spline curve”. Next I’m going to add a “transform spline curve to lines” command.
This is a good idea. I would repeat an earlier request to make it possible to choose an envelope type as an option before recording (in preferences or maybe a rightclick option as in Reaper) rather than converting it afterwards. Most of the material I make involves fairly smooth transitions so I tend to convert lots to splines anyway so it would be useful to just set it to splines unless I’m doing something that involves sharp transitions in which case I would keep it as it is (or would lines be better?)
rinxaijust a thought here – I’m interested in the possibility of automation curves derived/driven by a built in LFO thingy. 😉
else, good job on continued development – thanks. 🙂