BrainModular

Hello,


I started out with three SeqSwitch and by themselves they are not stepping in sync.
So I ran their step positions in serial. Woohoo all great, all run together now....except the first SeqSwitch

I decided okay lets take a clock and source the step position in serial. Strange it does not seem to be that this works as I am finding.
The first will respond to the clock, but will not pass on serially to the others. It just seems to have a default output for step pos instead of a through...hmmm

My assumptions were that this was a thru...if I set the position input...I would expect the output to be the same....

Anyone else see this?


-S

Odd too...I looped the step position between the three SeqSwitch...now 1 and 3 sync perfect and #2 has the lag.
Also noted if Pos is used such as with multiple samplers it seems the cursor synce between all slaves improves graphically...but the first one always jumps or is not visually in sync.

can you provide a example patch please..?

Yes I will get something uploaded. Seems I am getting better response now syncing all three without tying inputs/outputs with 1.02.008
Still odd responses though, probably intention however it doesnt seem logical

ok, thanks

My curiosity here is the unknown of where the step position is coming from when not hooked up. (obviously master synchro, but what outputs of?) (BTW I think it would be great to have the Trace Value be able to work on Inputs Only as well for this type of thing)
Seems integer based. Also wondering if the Step position input should completely override...or modules should have the ability to override their individual clock settings?

In 1.02.008 I seem to have improved movement. Say three sequenced switches, and the cursors will stay tighter in whole number movement.
I believe its more graphic performance related to syncronization. Curious if precision numbers have a higher priority on graphic response more than whole numbers? I see increased graphic performance/tighter syncronization when I tie step positions together. Instead of basing off of whole numbers, the cursors have more fluid motion and seem to stay in tighter sync (Like I would like to expect normally from HollyHock).

Remember the current computer I have is reporting GDI graphics (nvidia GTX275/250 with Dx11)
The top three seq in this workspace are just individual and in my setup they tend to lag by quite a bit...in the 1.02 I am seeing much tighter response. It seemed before one would just lag a great deal behind then jump to close position with the others. Now they are much closer but do show an irritating lag with eachother (not ideal performance for HollyHock) in my case

Experimenting the bottom red seqswitches the top two are daisy chained with the step position while the third one has an open input.
the top two have nice fluid motion and are really close...they are precision stepping rather than whole number stepping (this is getting closer to how I would expect HollyHock should graphically run in my setup). Curious though the bottom one is not matching since it is receiving whole number steps from ? ... but curious it actually outputs precision steps to the others. (At first I thought the IO for step position was a thru)

So I guess a work around would be to use a Primary for a set of modules and use that hidden to feed precision to all the others.
I think either that or rework a precision local clock to feed the project.....or possibly look into why whole number integers seem to graphically perform worse than precision...If precision runs better....I will always go with precision

I am curious if the graphics coding is requiring more cycles to process whole numbers, so far this is what I am seeing with my graphics performance.

So this is what I am seeing and discovering.
I would be very interested in a discussion on how the master syncro is being used globally for other modules.
And possibly a DIY local clock management

http://www.sensomusic.com/forums/upload ... eqsync.wkp

http://www.sensomusic.com/forums/upload ... qsync2.wkp

This arrangement also has me confused as well.
If I use the output of the step position as a data bus fed into another...it whole steps in response.
I even placing a trace shows precision from the Data Bus but the input step position does not act as intended.
If I plain wire one to the other the second one has the precision and smooth cursor.

I have even tried looping the positions to see what happens, 1-2-3 with 3 back to 1.
If you do this #3 becomes the whole stepper while #1 then gets the precision cursor. In all configurations no matter what one has to be a whole integer step?

-S

Hmmm.

Okay, this is another curiousity....so I just set two seqswitches to button....I used a clock and counter and adjusted for 16 step precision increments. Injected into the first routed out to the second. The First one likes to stay smooth the second one even though getting the precision jumps erratically.

Very confusing in respects to how these modules respond/interact...am I missing some key detail here?

http://www.sensomusic.com/forums/upload ... qsync3.wkp

Trace Output of Step Position of First SeqSwitch
Hmmm....looks like even though the master syncro is stopped a clock is mixing with my input...making me go back in time.
I assume this is the calculation clock being used for reference of the modules....seems to me that there should be an override so you can provide your own base clock. Maybe that is one of the problems users are facing is a clock collision, providing to many separate clocks resulting in too many calculations. I would expect that all modules requiring any timing should be "dead" unless fed a source reference. That source references (clock modules maybe ID as such) should be the only source for the patch modules, rather than providing the calculation clock to all modules direct then sticking another clock on top. Probably would be easier to trace inconsistencies in response to graphical and calculation performances as a baseline. If I had timing issues then I could look directly at latencies in-chain and resolve with buffering clocks out to each module.


I am just trying to come up with a theory...maybe instead of black boxing the calculation clock....
Options for sourcing the calculation clock/timing clocks would allow users to adjust for performance of their specific interface.
Currently if issues arise based on platform....users are hosed to experiment and come up with a stable performance.

I am starting to believe this is a lot of my source of problems in approach, as possibly well as others such as Seamus.
Understanding and Assumptions are left too wide open in regards to performance graphically as well as calculation timing in reference to modules.
If I can help write up some Trial and Error/Workaround documentation; I would love to to help others.

step pos[1]3
step pos[1]3.88000011444092
step pos[1]3.89000010490417
step pos[1]3
step pos[1]3.90000009536743
step pos[1]3
step pos[1]3.91000008583069
step pos[1]3
step pos[1]3.92000007629395
step pos[1]3
step pos[1]3.9300000667572
step pos[1]3
step pos[1]3.9300000667572
step pos[1]3.94000005722046
step pos[1]3
step pos[1]3.95000004768372
step pos[1]3
step pos[1]3.96000003814697
step pos[1]3
step pos[1]3.97000002861023
step pos[1]3
step pos[1]3.97000002861023
step pos[1]3.98000001907349
step pos[1]3
step pos[1]3.99000000953674
step pos[1]3
step pos[1]4
step pos[1]4.01000022888184
step pos[1]4
step pos[1]4.01999998092651
step pos[1]4
step pos[1]4.01999998092651
step pos[1]4.03000020980835
step pos[1]4
step pos[1]4.03000020980835

Okay my last post regarding for a bit...just my nature to experiment.
Regarding the mixing...almost looks like a ringing...I attached an Oscope...The red is the clock increase coming into the first SeqSwitch.
The Yellow is the output of the same SeqSwitch showing a triangle-type jitter or ringing.

http://www.sensomusic.com/forums/upload ... inging.wkp

Did the newest version fix these sync issues for you? It really had an impact on how Usine performs on my laptop (which is really more of a netbook).

the step pos inlet mustn't be a floating point value as you can see the on the fader itself
Only integer are allowed....
Usine try to round the input value to the nearest integer, so the out is strange.