ZynewaveYou cannot select multiple tracks. To move a range of tracks into a new group, right-click the first track and then use the “Move Track > Move To New Group” submenu.
Zynewave@Conquistador wrote:
2.0.7…
Windows and/or Podium generated this error…thought it might help to post it here.
Problem signature:
Problem Event Name: APPCRASH
Application Name: Podium.exe
Application Version: 2.7.0.0
Application Timestamp: 49286edd
Fault Module Name: kernel32.dll
Fault Module Version: 6.0.6001.18000
Fault Module Timestamp: 4791a81d
Exception Code: c0000005
Exception Offset: 00010e20
OS Version: 6.0.6001.2.1.0.256.1
Locale ID: 2057
Additional Information 1: fd00
Additional Information 2: ea6f5fe8924aaa756324d57f87834160
Additional Information 3: fd00
Additional Information 4: ea6f5fe8924aaa756324d57f87834160
Sorry, I didn’t yell out “A-HA” upon looking at these numbers. Could you provide more info, please?
ZynewaveThanks for the report. It turned out to be a bug. It is fixed in the latest 2.08 beta9. Let me know if everything works as expected.
ZynewaveBeta9 is up. This is hopefully the final beta. I would appreciate if some of you could try it out and report if everything is ok.
Among a few bug-fixes to the multi-take feature, there is this additional bug-fix:
Fix: Bypassing a mono device chained after a stereo device would only produce output in the left channel.
ZynewaveThis FR does not go to the top of the todo pile 😉
It cannot be an accurate duration estimate, as the processing may vary greatly along the timeline depending on the density of MIDI notes and automation. It would behave sort of like the “time remaining” info you get when you download files from the internet.
ZynewaveI’ve tried both of your described procedures with various plugins, but I cannot make it crash. I doubt your new audio interface should be the cause of the crashes.
Are the crashes random or can you reproduce it consistently?
Does it crash with different plugins?
Try if disabling the “plugin multiprocessing” option in preferences will get rid of the crashes.
Zynewave@ronin wrote:
btw. how is your guitar evolution proceeding?
I play a little every day. I’ve gotten the habit of grabbing the guitar during TV commercials 😉 (TV muted of course). I soon got bored with the online lessons I purchased, so I now just try to play my own stuff.
ZynewaveThe latest 2.08 beta8 now finally has a fix for this. Please let me know if you find further problems.
ZynewaveBeta8:
Using punch-out during recording will no longer deactivate recording mode. This allows punch-out to be used within a loop during multi-take recording.
Fix: The track solo changes introduced in 2.06 had the effect that bouncing the master would not produce sound if Automatic Solo was enabled on the bus returns.
Plus various fixes to the multi-take recording.
Zynewave@Conquistador wrote:
@Zynewave wrote:
After giving this some thought: Now that we have the “deactivate record mode when playback is stopped” option, it is no longer essential that punch-out disables record mode. It will thus be possible to keep loop-recording with punch-out inside the loop. It will also eliminate the confusion you had with why punch-out disables record mode when punch-in does not enable it. Anyone else have arguments against removing the record-disabling feature of punch-out?
The added flexibility is very welcome I must say. However Punch out disabling recording is still useful outside of loop recording. I would definitely want to keep it ❗
I think a global option should easily let a user set and forget the feature one way or another.
The punch out still disables recording of MIDI and audio beyond the punch-out position, no matter if looping is enabled or not. The only change is that the record button on the transport toolbar is not deselected once the punch-out position is reached. That is done with the new “deactivate record mode when playback is stopped” option. Please explain why you still want punch-out to deactivate recording?
Zynewave@Mike G wrote:
Why do you have punch-out enabled if you don’t want the recording to punch out?
For example you only want to try recording the first part of a loop without overwriting the 2nd part of the loop that you are alrady happy with. (1 bar) but the whole loop lasts 2 bars and you want to get the ryhthm, feel of the loop.
After giving this some thought: Now that we have the “deactivate record mode when playback is stopped” option, it is no longer essential that punch-out disables record mode. It will thus be possible to keep loop-recording with punch-out inside the loop. It will also eliminate the confusion you had with why punch-out disables record mode when punch-in does not enable it. Anyone else have arguments against removing the record-disabling feature of punch-out?
Try this… Set up a loop start/end. and then arm a new track for recording, starting recording from a few seconds before the start of the loop.
The purpose of this space before the loop is so in the first take you get a chance to count in, get your voice in tune with other notes etc.
The composite track (the bit with the right-click drop down list) and the first take start from the place I placed the play cursor to start recording. It took me a good while before I realised why I couldn’t make use of any of the other takes. The other takes are all shorter in length that the main compsite track length.
Would it not work as you intended if you set the punch-in at the loop start? That should ensure the comp event is only created at the loop start.
Zynewave@Conquistador wrote:
Wave form Peak Display.
As I understand it, this is not something that influences how comping should work, so I would prefer we discuss this another time. I’ve got plenty to do just implementing the composite track feature for this release.
Zynewave@Mike G wrote:
I set up a loop on a composite track and then set record punch-in and punch-out at the same length as loop.
When reaching the end of the first take, podium switched off recording.
It works OK if you just use punch-in and not punch out but I think it would be more intuitive for punch out not to permanently turn off recording when in a loop.
In fact now I come to think about it, why does punch-out turn off the recording button in general (especially when punch-in doesn’t enable record!)
Why do you have punch-out enabled if you don’t want the recording to punch out? The behaviour of punch-out in the scenario you describe seems ok to me. Maybe I would want to record just one loop-pass and then keep the loop running with playback of the take I just recorded.
Was using punch in to get around the fact that I have to cut the start of the loop with the scalpel tool in order to be able to select other takes. As a further suggestion would it be possible to do the scalpel cut at the start of the composite track by default?
I don’t understand this fully. Is it because you have recorded takes that starts beyond the start of the comp event? What do you mean with “the start of the composite track”?
Also would like takes to be named “Take 1”, “Take 2” (Or a,b,c) etc. when picking them in the drop down list on the composite track i would find that easier to remember which take was which as opposed to timestamp. (Maybe have timestamp as well)
If this corresponded with name of track that would be even better.BTW: Enjoying trying out new comping support, thanks fritz!
The timestamp naming is now optional in beta7. Thanks for the input.
Zynewave@Mike G wrote:
Suspected Bug…
Have a track with midi notes in a file starting at bar 2 (say).
Start recording a single note on bar 1 of track and let go of note before get to end of 1st bar.
All works OK.
BUT…
If I hold on note till after end of bar 1 so that the other notes in the existing midi file start playing then my original note never gets recorded.
Thanks,
Mike G
The problem is that the note would be cut off at the sequence end at bar 2, so the note would not play back as you played it. To ensure your MIDI recording is merged seamlessly into a sequence beyond your recording point, you need to predraw a sequence and merge it with the next sequence, so that it is one sequence.
ZynewaveBeta7:
There’s a new “Use timestamp as name for new take events” option in preferences. Disabling this option will then not set the name of the events, but instead use the name of the sound objects. The naming of the sounds on take tracks is now using a more sensible format such as: “Track 1: Take 1”.
Furthermore the following feature is added, which shows my original intention with the timestamped take events:
Setting a take on a composite event will set takes with similar names on all selected composite events. This is mostly useful if the “use timestamp as name for new take events” option is enabled and you are recording from multiple audio inputs. All takes recorded at a given time can thus easily be selected across all composite tracks.
And finally:
Added more detail to the “save changes” message box that appears when loading a new project or exiting Podium.