If you have a problem or need to report a bug please email : support@dsprobotics.com
There are 3 sections to this support area:
DOWNLOADS: access to product manuals, support files and drivers
HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects
USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here
NEW REGISTRATIONS - please contact us if you wish to register on the forum
Users are reminded of the forum rules they sign up to which prohibits any activity that violates any laws including posting material covered by copyright
Track Marker Move Event?
-
SBMastering
- Posts: 17
- Joined: Tue Jun 12, 2012 11:47 pm
Track Marker Move Event?
When you hit play in a DAW, you can move the track cursor around to skip to different parts of the recording during playback.
There is a component in Flowstone called "Is Playing", which always shows true even when you skip around with the track cursor. It seems that "Is Playing" only shows false when you actually hit stop.
Does anyone know of a way to detect when the track marker has been moved and create a boolean or trigger at that moment?
There is a component in Flowstone called "Is Playing", which always shows true even when you skip around with the track cursor. It seems that "Is Playing" only shows false when you actually hit stop.
Does anyone know of a way to detect when the track marker has been moved and create a boolean or trigger at that moment?
Re: Track Marker Move Event?
i think the "is playing" primitive does only show wether your host is actually in play mode or stopped - if its not stopped it will always show true, doesnt matter if you skip around and don´t actually "hear" something at this moment/ while skipping 
. maybe there is a workaround when you use the "ppq pos" primitive, you just have to find a way to detect if the stream output is linear rising (the standard behaviour when your host is running ) or not. maybe by comparing the actual ppq pos value with the prevois one? 
. maybe there is a workaround when you use the "ppq pos" primitive, you just have to find a way to detect if the stream output is linear rising (the standard behaviour when your host is running ) or not. maybe by comparing the actual ppq pos value with the prevois one?