jamulticore - Project Hosting on Google Code

| Sign in

Jamoma Multicore Audio Graph Layer

Project Home		Downloads		Wiki		Issues		Source

Summary | Updates | People

Details: Show all Hide all

1 - 50 Next ›

Earlier this year Aug 03, 2009 r33 (readme updates) committed by t...@electrotap.com - readme updates readme updates Aug 03, 2009 r32 (tagging release of 0.0.1) committed by t...@electrotap.com - tagging release of 0.0.1 tagging release of 0.0.1 Aug 03, 2009 r31 (preparing release of 0.0.1 - copy active branch to trunk) committed by t...@electrotap.com - preparing release of 0.0.1 - copy active branch to trunk preparing release of 0.0.1 - copy active branch to trunk Aug 03, 2009 r30 (preparing release of 0.0.1) committed by t...@electrotap.com - preparing release of 0.0.1 preparing release of 0.0.1 Aug 01, 2009 r29 (fix for dcblock extern instantiation) committed by t...@electrotap.com - fix for dcblock extern instantiation fix for dcblock extern instantiation Jul 31, 2009 r28 (multicore framework is building again) committed by t...@electrotap.com - multicore framework is building again multicore framework is building again Jun 26, 2009 r27 (all kinds of half-working changes that have accumulated over...) committed by t...@electrotap.com - all kinds of half-working changes that have accumulated over the last 5 months all kinds of half-working changes that have accumulated over the last 5 months Jun 26, 2009 r26 (making a place to check-in my completely broken copy of mult...) committed by t...@electrotap.com - making a place to check-in my completely broken copy of multicore making a place to check-in my completely broken copy of multicore Apr 20, 2009 issue 11 (Is PCM required for Multicore?) reported by t...@electrotap.com - From Skype... NILS PETERS: I am curious about the multicore layer 2:51 PM does it require a specific audio type ? 2:51 PM e.g. PCM 2:51 PM I mean Ambisonics B-Format is PCM in a way 2:52 PM but AC3 or Mp3 is not TIM PLACE: I guess it assumes PCM 2:52 PM but whether it requires it or not I haven't considered 2:53 PM The Multicore layer is defining a means by which objects are networked together -- not what the actual objects are doing 2:53 PM so It's conceivable that PCM is not required actually, but I never thought about this From Skype... NILS PETERS: I am curious about the multicore layer 2:51 PM does it require a specific audio type ? 2:51 PM e.g. PCM 2:51 PM I mean Ambisonics B-Format is PCM in a way 2:52 PM but AC3 or Mp3 is not TIM PLACE: I guess it assumes PCM 2:52 PM but whether it requires it or not I haven't considered 2:53 PM The Multicore layer is defining a means by which objects are networked together -- not what the actual objects are doing 2:53 PM so It's conceivable that PCM is not required actually, but I never thought about this Jan 27, 2009 DesignConsiderations (Current thoughts and planning for design of the system.) Wiki page edited by t...@electrotap.com Jan 27, 2009 DesignConsiderations (Current thoughts and planning for design of the system.) Wiki page edited by t...@electrotap.com Jan 21, 2009 r23 (fix for uninitialized memory) committed by t...@electrotap.com - fix for uninitialized memory fix for uninitialized memory Jan 21, 2009 r22 (validity checking before sending notifications to observers ...) committed by t...@electrotap.com - validity checking before sending notifications to observers -- this resolves some crashing problems -- would like to come back some time and review exactly how everything is happening though... validity checking before sending notifications to observers -- this resolves some crashing problems -- would like to come back some time and review exactly how everything is happening though... Jan 21, 2009 r21 (out≈: fixed memory leak) committed by t...@electrotap.com - out≈: fixed memory leak out≈: fixed memory leak Jan 21, 2009 r20 (* Proper object life-cycle management for internal buffer ...) committed by t...@electrotap.com - * Proper object life-cycle management for internal buffer -- not having this causes memory corruption because the reference counting on the object was wrong! * Perhaps we should make the constructors for TTObjects private? * Proper object life-cycle management for internal buffer -- not having this causes memory corruption because the reference counting on the object was wrong! *** Perhaps we should make the constructors for TTObjects private? Jan 21, 2009 r19 (safety improvements for setting audio pointer) committed by t...@electrotap.com - safety improvements for setting audio pointer safety improvements for setting audio pointer Jan 21, 2009 r18 (Adding generator flag to in≈ -- this is required because thi...) committed by t...@electrotap.com - Adding generator flag to in≈ -- this is required because this object processes no input. Adding generator flag to in≈ -- this is required because this object processes no input. Jan 21, 2009 r17 (memory corruption fix for objects with multiple inlets) committed by t...@electrotap.com - memory corruption fix for objects with multiple inlets memory corruption fix for objects with multiple inlets Jan 20, 2009 r16 (no works with the new way of releasing TT objects) committed by t...@electrotap.com - no works with the new way of releasing TT objects no works with the new way of releasing TT objects Jan 20, 2009 r15 (initial matrix≈ object) committed by t...@electrotap.com - initial matrix≈ object initial matrix≈ object Jan 19, 2009 r14 (updated projects to new build configurations, also moved the...) committed by t...@electrotap.com - updated projects to new build configurations, also moved the build script out to the jatuuls project. updated projects to new build configurations, also moved the build script out to the jatuuls project. Jan 19, 2009 r13 (updated projects to new build configurations, also moved the...) committed by t...@electrotap.com - updated projects to new build configurations, also moved the build script out to the jatuuls project. updated projects to new build configurations, also moved the build script out to the jatuuls project. Older Nov 20, 2008 issue 3 (Dynamic re-patching for Max implementation) commented on by t...@electrotap.com - deleting objects is implemented -- adding objects, or (more specifically) connecting objects is not yet implemented. Also will have to work on disconnecting objects. deleting objects is implemented -- adding objects, or (more specifically) connecting objects is not yet implemented. Also will have to work on disconnecting objects. Nov 20, 2008 issue 5 (Crashes if closing a patcher or deleting an object while the...) Status changed by t...@electrotap.com - Status: Fixed Status: Fixed Nov 20, 2008 issue 5 (Crashes if closing a patcher or deleting an object while the...) Cc changed by t...@electrotap.com - This is implemented as of SVN rev 12. The dac≈ help patcher no longer crashes when freeing an object and the audio is still running. It is also a big step toward dynamic re-patching with the audio running. For example, create a patcher with 3 oscillators and start the audio. If you delete one oscillator while the audio is running then you simply cease to hear it any more while the other 2 oscillators continue to run. Cc: nils.peters trond.lo...@bek.no This is implemented as of SVN rev 12. The dac≈ help patcher no longer crashes when freeing an object and the audio is still running. It is also a big step toward dynamic re-patching with the audio running. For example, create a patcher with 3 oscillators and start the audio. If you delete one oscillator while the audio is running then you simply cease to hear it any more while the other 2 oscillators continue to run. Cc: nils.peters trond.lo...@bek.no Nov 20, 2008 r12 (Dynamic patching part 1: objects can now be deleted while th...) committed by t...@electrotap.com - Dynamic patching part 1: objects can now be deleted while the dsp is running (for example by the dac≈ object). When this happens they are simply not called anymore and the rest of the audio graph continues to run without interruption. One effect of this is that the dac≈ help patcher should no longer crash and thus Issue 5 is resolved. Dynamic patching part 1: objects can now be deleted while the dsp is running (for example by the dac≈ object). When this happens they are simply not called anymore and the rest of the audio graph continues to run without interruption. One effect of this is that the dac≈ help patcher should no longer crash and thus Issue 5 is resolved. Nov 20, 2008 issue 8 (test that audio is not broken when dynamically repatching) Status changed by t...@electrotap.com - duplicate of issue 3 Status: Duplicate duplicate of issue 3 Status: Duplicate Nov 20, 2008 issue 3 (Dynamic re-patching for Max implementation) commented on by t...@electrotap.com - the audio should not be broken by a complete signal chain rebuild the audio should not be broken by a complete signal chain rebuild Nov 20, 2008 r11 (even less verbose output) committed by t...@electrotap.com - even less verbose output even less verbose output Nov 20, 2008 r10 (less verbose build script when copying help patchers) committed by t...@electrotap.com - less verbose build script when copying help patchers less verbose build script when copying help patchers Nov 20, 2008 r9 (Fix for crash in dac≈ when it has no input feeding it.) committed by t...@electrotap.com - Fix for crash in dac≈ when it has no input feeding it. Fix for crash in dac≈ when it has no input feeding it. Nov 19, 2008 issue 10 (Object naming for Max) reported by t...@electrotap.com - Currently we have been using the ≈ character as a suffix for identifying multicore objects. This presents a host of issues due to it not being a normal ASCII character. One way around it is to simply use the = character. Another way is to name the objects with a prefix, e.g.: m.in m.overdrive m.out Then perhaps we could use an object mapping or something to allow the names to be typed as in≈, out≈, etc. Currently we have been using the ≈ character as a suffix for identifying multicore objects. This presents a host of issues due to it not being a normal ASCII character. One way around it is to simply use the = character. Another way is to name the objects with a prefix, e.g.: m.in m.overdrive m.out Then perhaps we could use an object mapping or something to allow the names to be typed as in≈, out≈, etc. Nov 19, 2008 issue 9 (test / work with Max sub-patchers) Labels changed by t...@electrotap.com - any time the dsp chain is compiled, and such compilation is driven by an object in a sub-patcher (such as out≈) then that object should crawl through the entire patcher heirarchy. e.g: // iterate to parent while (pp = (t_jpatcher )jpatcher_get_parentpatcher((t_object )p)) p = pp; And then work downward. Perhaps if we wanted a global build (because of sends and receives -- which need to be tested) then we can ask Max for a list of all windows and traverse that getting the patchers from them. Labels: Priority-High −Priority-Medium any time the dsp chain is compiled, and such compilation is driven by an object in a sub-patcher (such as out≈) then that object should crawl through the entire patcher heirarchy. e.g: // iterate to parent while (pp = (t_jpatcher )jpatcher_get_parentpatcher((t_object )p)) p = pp; And then work downward. Perhaps if we wanted a global build (because of sends and receives -- which need to be tested) then we can ask Max for a list of all windows and traverse that getting the patchers from them. Labels: Priority-High −Priority-Medium Nov 19, 2008 issue 1 (Support for Jamoma Modular) commented on by trond.lo...@bek.no - I think we for the time being should have a specific module converting from MSP to multicore, and similarly we should have one module converting from multicore to MSP. If ether jcom.in/jcom.out or jcom.in~/jcom.out~ could be extended to accept multicore objects, we could let do without having to create additional externals. Another option would be to have just one jcom.in/jcom.out pair, and use arguments (none, msp, multicore) to decide during the new() method how to instantiate. Unles DSP issues have to be settled in main() this would be the cleanest solution. I think we for the time being should have a specific module converting from MSP to multicore, and similarly we should have one module converting from multicore to MSP. If ether jcom.in/jcom.out or jcom.in~/jcom.out~ could be extended to accept multicore objects, we could let do without having to create additional externals. Another option would be to have just one jcom.in/jcom.out pair, and use arguments (none, msp, multicore) to decide during the new() method how to instantiate. Unles DSP issues have to be settled in main() this would be the cleanest solution. Nov 17, 2008 TheoryOfOperation (The theory of operation for how a multicore audio graph is b...) Wiki page added by t...@electrotap.com Nov 17, 2008 issue 9 (test / work with Max sub-patchers) reported by t...@electrotap.com - This probably doesn't work right now because the broadcast is only for the current patcher. Should it be global? Should it be only looking downward? Also upward? How well do bindings carry through patch cords? What about send and receive? This probably doesn't work right now because the broadcast is only for the current patcher. Should it be global? Should it be only looking downward? Also upward? How well do bindings carry through patch cords? What about send and receive? Nov 17, 2008 issue 8 (test that audio is not broken when dynamically repatching) reported by t...@electrotap.com - this requires that the dynamic patching work first this requires that the dynamic patching work first Nov 17, 2008 issue 7 (simple FM example) reported by t...@electrotap.com - this will prove whether or not the optional audio input for oscil≈ (for modulating the frequency) works. this will prove whether or not the optional audio input for oscil≈ (for modulating the frequency) works. Nov 17, 2008 issue 6 (phasor≈) reported by t...@electrotap.com - This object is desired and should be easy. Perhaps can serve as a test case for using the Maxbær wrapper on a generator. This object is desired and should be easy. Perhaps can serve as a test case for using the Maxbær wrapper on a generator. Nov 17, 2008 issue 5 (Crashes if closing a patcher or deleting an object while the...) reported by t...@electrotap.com - We need some way to listen for object deletions in the audio graph, and then respond to them in some way. Probably this means we have to call a MCoreFree() method of some sort when the external is freed. Or may it should be MaxMulticoreFree() vs. MulticoreFree()? We need some way to listen for object deletions in the audio graph, and then respond to them in some way. Probably this means we have to call a MCoreFree() method of some sort when the external is freed. Or may it should be MaxMulticoreFree() vs. MulticoreFree()? Nov 17, 2008 issue 4 (filter design example) reported by t...@electrotap.com - This will require a vector size of 1 for a chain with a delay and feedback. That means that we need to implement a vectorSize attribute for the out≈ object. This will require a vector size of 1 for a chain with a delay and feedback. That means that we need to implement a vectorSize attribute for the out≈ object. Nov 17, 2008 issue 3 (Dynamic re-patching for Max implementation) reported by t...@electrotap.com - the configuration of the audio graph needs to be updated in response to the listening to a patcher for notifications. the configuration of the audio graph needs to be updated in response to the listening to a patcher for notifications. Nov 17, 2008 issue 2 (op≈ object needs multiple signal inputs) reported by t...@electrotap.com - Other examples where similar issues may be involved include crossfade≈, pan≈, matrix≈, etc. Other examples where similar issues may be involved include crossfade≈, pan≈, matrix≈, etc. Nov 17, 2008 issue 1 (Support for Jamoma Modular) reported by t...@electrotap.com - Multicore support for jcom.in and jcom.out. Do we need all of the following? * jcom.in≈ and jcom.out≈ (work with multicore signals) * jcom.in~≈ and jcom.out≈~ (multicore internally, but msp externally) * jcom.in≈~ and jcom.out~≈ (msp internally, but multicore externally) How do we settle this? The idea of breaking compatibility in Jamoma is ugly :-(. Multicore support for jcom.in and jcom.out. Do we need all of the following? * jcom.in≈ and jcom.out≈ (work with multicore signals) * jcom.in~≈ and jcom.out≈~ (multicore internally, but msp externally) * jcom.in≈~ and jcom.out~≈ (msp internally, but multicore externally) How do we settle this? The idea of breaking compatibility in Jamoma is ugly :-(. Nov 14, 2008 r7 (build script is now working) committed by t...@electrotap.com - build script is now working build script is now working Nov 14, 2008 r6 (Added missing main.cpp file for the JamomaMulticore framewor...) committed by t...@electrotap.com - Added missing main.cpp file for the JamomaMulticore framework. Added missing main.cpp file for the JamomaMulticore framework. Nov 14, 2008 r5 (All objects seem to be working properly now.) committed by t...@electrotap.com - All objects seem to be working properly now. All objects seem to be working properly now. Nov 14, 2008 r4 (Initial add of sources pulled from the TTBlue repository.) committed by t...@electrotap.com - Initial add of sources pulled from the TTBlue repository. Initial add of sources pulled from the TTBlue repository. Nov 14, 2008 r3 (creating an active branch) committed by t...@electrotap.com - creating an active branch creating an active branch Nov 14, 2008 DesignConsiderations (Current thoughts and planning for design of the system.) Wiki page added by t...@electrotap.com

1 - 50 Next ›

Hosted by