Extended Channels and *.chan... Is that bug?

   4398   7   0
User Avatar
Member
398 posts
Joined: July 2005
Offline
Try to extend a channel by Extend CHOP and save that channel to *.chan/*.bchan file (with *.clip/*.bclip all must be okay) and read that file back. I'm sure you will see just old channel, not new “extended” channel. So is it bug?
f = conserve . diffuse . advect . add

fx td @ the mill
User Avatar
Member
7733 posts
Joined: July 2005
Online
As you'll note in the CHOPs Viewer, the Extend CHOP simply modifies the conditions of how the channel is evaluated past it's end points because only the dotted lines change. Since the .chan file format only records the actual data points, this information is lost if you use it. I think the .chan format dates back to PRISMS for which extend conditions didn't exist?
User Avatar
Member
398 posts
Joined: July 2005
Offline
I see your point but why we can't save the _raw_ values of extended channel to *.chan? In the theory nothing can't stop us from grabbing any value and saving it. ops:
f = conserve . diffuse . advect . add

fx td @ the mill
User Avatar
Member
7733 posts
Joined: July 2005
Online
But extend conditions extend to infinity. So how many raw values should it write out?
User Avatar
Member
398 posts
Joined: July 2005
Offline
So how many raw values should it write out?
I think `$RFEND - $RFSTART + 1`
f = conserve . diffuse . advect . add

fx td @ the mill
User Avatar
Member
7733 posts
Joined: July 2005
Online
That may or may not be valid though. Have you tried opsave?
User Avatar
Member
398 posts
Joined: July 2005
Offline
What do you mean, Edward?
f = conserve . diffuse . advect . add

fx td @ the mill
User Avatar
Member
7733 posts
Joined: July 2005
Online
I mean, that may or may not be what the user wants. Esp. if they have chop data that exceeds the range .
  • Quick Links