Any inside track on next DP release?

[SixStringGeek]

Sorry SSG, as a long-time sailor myself, I know full well the difference between sheet and sheep. It was a play on words.

Given your name, two actually.

[HCMarkus]

Upon the slitted sheet I sit... That's knot my bag, baby!

[twistedtom]

So I will not be sheepish and hope you do not pull the wool over my eyes. I will ask is DP knot coming out with an upgrade soon?

My stupid guess is that there is a chance they may have a few fixes in the works and if so they may release an up grade. If not then they will wait for it to Snow. When it Snows it may be DP7. Then DP7.01 /7.012 /7.013/7.014 where they get it all working until some one upgrades some thing else.

Now I am going to get 3 sheets to the wind with 3 sheep.

[htiek]

Just a suggestion for MOTU developers of Digital Performer. It's pretty clear to me, since my computer crashes repeatedly after a short time running DP, that on the Mac side at least, you need to separate the platform into Apple Silicon and Intel. Combining the two isn't working. There are still lots of people on Intel based Macs, but trying to combine the code for both platforms, makes it impossible to trace problems with Mac OS, plugins, and startup applications. I have updated everything until I'm blue in the face and sent numerous crash reports to MOTU and no one seems to know what the problem is. Perhaps also separate by MAC OS, pre and post Apple Silicon.

[stubbsonic]

First of all, welcome to the forum.

Second, thanks for taking me on an hilarious ride. I start reading page one about someone asking if there are hints about when the next bug-fix update is coming. (Only to find that it is from 15 years ago. LOL)

I too have had less-than-smooth-sailing with DP. For me, it has been many years. I've tried other DAWs and always come whimpering back. So as the OP of this thread suggested 15 years ago, it would be great if they could do a big push to clean it all up, get it all stable, and even go through ALL the legacy features and make sure they are appropriately perky.

I've never heard anything about universal (intel/AS) software "duality" causing problems. Presumably, each platform only runs its compatible parts of the application, and the application would shares whatever data is not platform specific.

I guess I have seen some developers release separate installers for intel & AS, I don't know what the (dis)advantages to either approach.

[James Steele]

I've never heard anything about universal (intel/AS) software "duality" causing problems.

Me, either.

I guess I have seen some developers release separate installers for intel & AS, I don't know what the (dis)advantages to either approach.

I’ve seen plug-in developers do this. PSP used to during the initial transition to Apple Silicon but no longer do. But I have never seen this done with applications.

[bayswater]

Obviously there are problems adapting to AS that can be seen in many apps, but I’m not seeing any new problems with Intel. As Jon mentions there are a lot of old functions in DP left over from the time we all had a lot more hardware, and these need to be updated. There are long standing bugs that will not be solved by hiving off a separate AS version.

And IIRC, when developers last had to support two processors, many if not most, just put the code for both into one executable file. The app was aware of the processor on the host, so it just ran the code for that processor. There were some utilities around that let you remove the code specific to the old processor if you wanted to save the space. I think Monolingual will still do that.

So you could have separate versions, and all the support issues that creates, or just bung it all in one file. Makes no difference — it’s buggy code that needs to be addressed.

[Michael Canavan]

Personally it's always at least 95% plugins that crash DP. Mostly IMO DP fights it's own uniqueness in hosting etc. and not being the main test platform for the three plugin types it can host. IMO it's not about the Intel to Apple Silicon transition, at least in terms of what is crashing DP the most. You can look at your crash report, it's usually not too hard to figure out, and it's almost always without exception a thread with one plugin popping up.

The one feature that DP could benefit from if it would be possible for them to implement is plugin sandboxing. Essentially plugins run as their own process so they do not crash the DAW if they have incompatibilities, the plugin itself crashes instead. In Bitwig it's implemented with the ability to restart the plugin right in the DAW without restarting the DAW.

The other DAW I know of that does this is Reaper, but the implementation is sketchy by their own accounts, i.e. they recommend implementing it only for problematic plugins. In many ways Reaper is closer to DP in it's complexity so this might be how it could look if MOTU were to implement something like this.

[stubbsonic]

That's an interesting point. I've not noticed any consistent pattern about whether I'm running plugins or not when I get crashes. I might also be a bit skeptical that your experiences and interpretation of crash reports reflect a generality about all of our issues with DP stability. You might be right, but I'll just reserve judgement about that.

When DP crashes in the right way to generate a report, I kind of assumed the report goes to Apple, and then gets forwarded (or at least made available) to the developer. So MOTU developers could see that plugins are causing some issues and address it one way or another.

I have no earthly how to read a crash report. I wish someone would make an AI crash report reader.

[Michael Canavan]

That's an interesting point. I've not noticed any consistent pattern about whether I'm running plugins or not when I get crashes. I might also be a bit skeptical that your experiences and interpretation of crash reports reflect a generality about all of our issues with DP stability. You might be right, but I'll just reserve judgement about that.

When DP crashes in the right way to generate a report, I kind of assumed the report goes to Apple, and then gets forwarded (or at least made available) to the developer. So MOTU developers could see that plugins are causing some issues and address it one way or another.

I have no earthly how to read a crash report. I wish someone would make an AI crash report reader.

So it's not impossible to read crash reports even as a non coder etc. When they pop up, the first thing to look for is which thread crashed, they always mention this in the first couple "paragraphs". So it will say "Crashed thread - Thread 39", you got the section clearly marked Thread 39, and look for plugins. When it's a crash that does not involve a plugin none will be mentioned in that thread. For instance I can reliably crash DP every single time by dragging a REX file into DP, you will not see a plugin mentioned in the crashed thread.

This is how I've come to this conclusion. A couple decades of troubleshooting crashes in DP and other DAWs. Right now, the main culprit in DP for me is the MPC 2 plugin, it shows up nearly every time DP crashes, and I've switched in projects I can switch anyway, to Kontakt and Battery for drum libraries etc.

There is no indication to me that Apple uses it's retrieved crash reports to inform developers, and IMO it's even more unlikely that they would with our tiny community of end users, developers etc.

[stubbsonic]

There is no indication to me that Apple uses it's retrieved crash reports to inform developers, and IMO it's even more unlikely that they would with our tiny community of end users, developers etc.

Thanks for that helpful explanation of crash reports. I'll definitely pay careful attention to that, going forward.

I had a little conversation with a developer who said that as long as I had some kind of diagnostic data sharing enabled, he could "pull" crash reports and look at them-- which I enabled and he did. So I guess that is at least one avenue, but I usually keep all that turned off.

[Michael Canavan]

There is no indication to me that Apple uses it's retrieved crash reports to inform developers, and IMO it's even more unlikely that they would with our tiny community of end users, developers etc.

Thanks for that helpful explanation of crash reports. I'll definitely pay careful attention to that, going forward.

I had a little conversation with a developer who said that as long as I had some kind of diagnostic data sharing enabled, he could "pull" crash reports and look at them-- which I enabled and he did. So I guess that is at least one avenue, but I usually keep all that turned off.

With Ableton they have their own internal crash report container they immediately ask you to send to support if a crash happens, it's pretty clever but it overrides Apples it seems. At least here DP crashes generate an Apple crash report, so you can read it yourself if you want to.

[cuttime]

Here's a bit of a crash report I had from a version of Kontakt 7 that was pretty reliably crashing DP last year. It was pretty obvious:


Thread 0 Crashed:
0 libsystem_malloc.dylib 0x185ae2188 tiny_malloc_from_free_list.cold.3 + 0
1 libsystem_malloc.dylib 0x185ac03c0 tiny_malloc_from_free_list + 1744
2 libsystem_malloc.dylib 0x185abf670 tiny_malloc_should_clear + 216
3 libsystem_malloc.dylib 0x185abe24c szone_malloc_should_clear + 92
4 libsystem_collections.dylib 0x191615a44 os_map_64_init + 92
5 libsystem_notify.dylib 0x188f08388 _notify_fork_child + 248
6 libSystem.B.dylib 0x19162fa60 libSystem_atfork_child + 60
7 libsystem_c.dylib 0x185b55944 fork + 112
8 Kontakt 7 0x4f6fd29b8 boost::process::detail::posix::executor<boost::fusion::joint_view<boost::fusion::tuple<boost::process::detail::posix::exe_cmd_init<char>, boost::process::detail::set_on_error>, boost::fusion::filter_view<boost::fusion::tuple<boost::filesystem::path&, char const (&) [3], std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>&, std::__1::error_code&, boost::process::detail::posix::sig_init_&> const, boost::process::detail::is_initializer<mpl_::arg<-1>>>>>::invoke(mpl_::bool_<false>, mpl_::bool_<false>) + 836
9 Kontakt 7 0x4f6fd120c boost::process::child boost::process::detail::basic_execute_impl<char, boost::filesystem::path, char const (&) [3], std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>&, std::__1::error_code&, boost::process::detail::posix::sig_init_>(boost::filesystem::path&&, char const (&) [3], std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>&, std::__1::error_code&, boost::process::detail::posix::sig_init_&&) + 296
10 Kontakt 7 0x4f6fd0708 ni::odr::ipc::start_agent() + 256
11 Kontakt 7 0x4f6ff49dc ni::odr::ipc::kks::ipc_client_core::connect(strong::type<bool, ni::odr::ipc::kks::agent_autostart_tag>) + 68
12 Kontakt 7 0x4f6fe6500 void boost_asio_handler_invoke_helpers::invoke<boost::asio::detail::binder0<ni::odr::ipc::kks::ipc_client::connect_to_agent(std::__1::function<void (tl::expected<void, std::exception_ptr>)>, strong::type<bool, ni::odr::ipc::kks::agent_autostart_tag>)::$_1>, boost::asio::detail::binder0<ni::odr::ipc::kks::ipc_client::connect_to_agent(std::__1::function<void (tl::expected<void, std::exception_ptr>)>, strong::type<bool, ni::odr::ipc::kks::agent_autostart_tag>)::$_1>>(boost::asio::detail::binder0<ni::odr::ipc::kks::ipc_client::connect_to_agent(std::__1::function<void (tl::expected<void, std::exception_ptr>)>, strong::type<bool, ni::odr::ipc::kks::agent_autostart_tag>)::$_1>&, boost::asio::detail::binder0<ni::odr::ipc::kks::ipc_client::connect_to_agent(std::__1::function<void (tl::expected<void, std::exception_ptr>)>, strong::type<bool, ni::odr::ipc::kks::agent_autostart_tag>)::$_1>&) + 80
13 Kontakt 7 0x4f6fe84f4 boost::asio::detail::executor_op<boost::asio::detail::binder0<ni::odr::ipc::kks::ipc_client::connect_to_agent(std::__1::function<void (tl::expected<void, std::exception_ptr>)>, strong::type<bool, ni::odr::ipc::kks::agent_autostart_tag>)::$_1>, std::__1::allocator<void>, boost::asio::detail::scheduler_operation>::do_complete(void*, boost::asio::detail::scheduler_operation*, boost::system::error_code const&, unsigned long) + 264
14 Kontakt 7 0x4f8728490 boost::asio::detail::scheduler::do_run_one(boost::asio::detail::conditionally_enabled_mutex::scoped_lock&, boost::asio::detail::scheduler_thread_info&, boost::system::error_code const&) + 672
15 Kontakt 7 0x4f8723030 boost::asio::detail::scheduler::run(boost::system::error_code&) + 196
16 Kontakt 7 0x4f8722f1c boost::asio::io_context::run() + 32
17 Kontakt 7 0x4f6fe1d14 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct>>, ni::odr::ipc::kks::ipc_client::ipc_client(ni::odr::instance_info, std::__1::shared_ptr<ni::odr::ipc::kks::abstract_ipc_client_observer>, std::__1::unique_ptr<ni::odr::ipc::abstract_main_thread_dispatcher, std::__1::default_delete<ni::odr::ipc::abstract_main_thread_dispatcher>>, std::__1::basic_string_view<char, std::__1::char_traits<char>>)::$_7>>(void*) + 152
18 libsystem_pthread.dylib 0x185c9bfa8 _pthread_start + 148
19 libsystem_pthread.dylib 0x185c96da0 thread_start + 8

[nk_e]

Personally it's always at least 95% plugins that crash DP. Mostly IMO DP fights it's own uniqueness in hosting etc. and not being the main test platform for the three plugin types it can host. IMO it's not about the Intel to Apple Silicon transition, at least in terms of what is crashing DP the most. You can look at your crash report, it's usually not too hard to figure out, and it's almost always without exception a thread with one plugin popping up.

The one feature that DP could benefit from if it would be possible for them to implement is plugin sandboxing. Essentially plugins run as their own process so they do not crash the DAW if they have incompatibilities, the plugin itself crashes instead. In Bitwig it's implemented with the ability to restart the plugin right in the DAW without restarting the DAW.

The other DAW I know of that does this is Reaper, but the implementation is sketchy by their own accounts, i.e. they recommend implementing it only for problematic plugins. In many ways Reaper is closer to DP in it's complexity so this might be how it could look if MOTU were to implement something like this.

Crash reports have always been a frustrating mystery to me. Frustrating because I know it contains answers, yet it’s wrapped in a mystery and so the info is unavailable.

Something I have found to be really helpful is to copy the beginning of the crash report along with the crashed thread and feed that into ChatGPT and ask it to explain. It spits back an answer I can understand with enough information to be helpful…what (plugin) caused the crash, what it was trying to do when it crashed, other processes involved, etc. Very helpful.

As far as sandboxing goes, Bitwig’s implementation is superb and offers levels of granularity. You can sandbox individual plugins, all of a developer’s plugins in one sandbox (to facilitate intra plugin communication), or choose no sandboxing. If a plugin crashes a window pops up informing you and you have the option of restarting the plugin and continuing on. It works like a charm and has saved my butt on more than one occasion, ALL DAWs should operate this way.

[Michael Canavan]

As far as sandboxing goes, Bitwig’s implementation is superb and offers levels of granularity. You can sandbox individual plugins, all of a developer’s plugins in one sandbox (to facilitate intra plugin communication), or choose no sandboxing. If a plugin crashes a window pops up informing you and you have the option of restarting the plugin and continuing on. It works like a charm and has saved my butt on more than one occasion, ALL DAWs should operate this way.

It's just a big "if" whether it's possible for a DAW with PreGen can do the sort of sandboxing that Bitwig can though. It might be partly due to Bitwigs lack of dual buffers for saving CPU on projects that they can sandbox plugins.

But... if MOTU could do this with DP I would bet money it would solve a long standing shortcoming of Chunks and V-Racks, namely that V-Rack hosted plugins cannot use plugin/track automation, only MIDI automation. Since the plugin would be running in its own process it should be capable of interacting with any individual Chunk etc.

Anyway DAW pipe dreams right?