Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Roadmap #317

Closed
porres opened this issue May 3, 2017 · 4 comments
Closed

Roadmap #317

porres opened this issue May 3, 2017 · 4 comments

Comments

@porres
Copy link
Owner

porres commented May 3, 2017

No description provided.

@mrufrufin
Copy link
Contributor

so we want to copy over the given wavetable to a specific [cycle~] instance? or have somehow global [cycle~] tables bound to symbols? what benefits/differences are there for copying over tables? besides possibly still having access to a table if you delete the array.

@mrufrufin
Copy link
Contributor

mrufrufin commented Jul 12, 2017

Overhead concerns I suppose being one of them, namely say if you have 1000 of them, like if they're in an abstraction and you load that abstraction via [clone] (but then I suppose perhaps wavetables shouldn't be that long anyays? but what if they are. also consider the situation when you're changing the wavetable to all of them vs just changing what array they're looking at). I suppose it should be a per-instance thing since instroducing a whole new namespace of symbols for cycle would get confusing as heck.

So then I suppose that passing the symbol argt for cycle~ should refer to the array as is, so if you have an array "susie" (say, of white noise) and you have [cycle~ susie], it copies susie into its own table, but then you fill susie with I dunno, a with a sinesum, then susie's contents have changed, [cycle~ susie] did not, which is what you're saying.

that situation could get a little confusing if we added a new [cycle~ susie] and since susie is now a bunch of sines, this new [cycle~ susie] would be a bunch of sines, despite looking exactly like the old [cycle~ susie], which has white noise in it bc that's what susie had when we instantiated that one.

@mrufrufin
Copy link
Contributor

do you mean actual array size or loopstart and end?

if we're talking about actual array size, the problem is that it's recording into the array proper that you pass. that is, if there's [array define bob], and [record~ bob], you're recording into bob directly, you're not recording locally and copying it over, so if your new array size is smaller than loopend, that's no good and you're trying to record into array that isn't there. i suppose mb then you could implement a safeguard and not write into the array if it goes past the array size but have sync pretend it's still actually recording?

might not have time to address this for a while, but there are thoughts =P

@porres
Copy link
Owner Author

porres commented Feb 13, 2018

rebooting this

@porres porres closed this as completed Feb 13, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants